Re: Deprecating XUL in new UI

[David Bolter]

Hi all, so as not to leave this hanging:

On Tue, Jan 17, 2017 at 9:24 AM, Axel Hecht  wrote:

> Am 16/01/2017 um 21:43 schrieb Dave Townsend:
>
>>
>> What other features do we depend on in XUL that I haven't listed?
>>
>>
> Accessibility? Not sure how big the difference is there between XUL and
> HTML.
>

Thanks for bringing this up. There is almost no difference and we're
covered here.

Cheers,
D
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecating XUL in new UI

[David Bolter]

On Tue, Jan 17, 2017 at 12:55 PM, Bobby Holley 
wrote:

> On Tue, Jan 17, 2017 at 8:56 AM, Boris Zbarsky  wrote:
>
> > On 1/16/17 4:28 PM, Matthew N. wrote:
> >
> >> Does it just work from XHTML documents?
> >>
> >
> > Yes, as far as I know.
> >
> > Is our implementation of Web Components ready to replace it and riding
> the
> >> trains?
> >>
> >
> > No.
> >
>
>
> From the perspective of the platform, my general experience is that XBL is
> much, much more of a PITA than XUL itself. I would be very skeptical of a
> plan to start using some form of heavily-XBL-reliant HTML.
>
> I have generally ambivalent feelings towards XUL, but XBL cannot die fast
> enough.
>

Should (can) it die in the Quantum development timeframe?  What does that
do to shipping risk? I realize churn creates risk, but I seem to recall XBL
is getting in the way for Quantum styling?

Cheers,
David


>
> bholley
>
>
> >
> > -Boris
> >
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Creating a content process during shutdown...

[David Bolter]

Hi Gabor, I'm interested in shutdown issues. Is there a bug # for this case?
Cheers,
D

On Thu, Sep 21, 2017 at 4:08 AM, Gabor Krizsanits 
wrote:

> I guess the question is how do you define "after we've entered shutdown".
>
> For the preallocated process manager both "profile-change-teardown" and
> "xpcom-shutdown" will prevent any further process spawning. For the
> preloaded browser in tabbrowser.xml we usually instead of creating a
> process for the hidden about:blank page we select an existing one, however
> if there is non around (the browser has only some chrome pages open when
> the shutdown is initiated) then it can create a process and I'm not sure if
> anything would prevent the process creation now that I'm thinking about it.
>
> I think we should set some flag when some of these shutdown related
> notifications are fired and based on that prevent any new content process
> creation somewhere in ContentParent::LaunchSubprocess. Since I don't see
> any legit use case for it and I'm pretty sure it usually ends up with
> crashes or hangs.
>
> Gabor
>
> On Wed, Sep 20, 2017 at 8:38 PM, Milan Sreckovic 
> wrote:
>
> > I've spoken to some of you about this, but at this point need a larger
> > audience to make sure we're covering all the bases.
> >
> > Do we have code in Firefox that would cause us to create a new content
> > process, after we've entered shutdown?
> >
> > I understand the possibility of user action that would create a new
> > content process followed quickly by one that would cause shutdown, and
> the
> > timing making it so that the new content process initialization can then
> > happen out of order, but I'm more asking about the explicit scenario.
> >
> > Thanks!
> >
> > --
> > - Milan (mi...@mozilla.com)
> >
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Performance issue on 57 with some a11y clients

[David Bolter]

Hi folks,


As you may have heard, some users on 57 are experiencing performance
problems due to third party clients that are interacting poorly with
Firefox accessibility. We have been able to reproduce only one case
(Realplayer) and need more. So here’s what we are asking. If you use
Windows can you try this:


   1.

   In about:config, ensure accessibility.force_disabled is 0.
   2.

   Restart Firefox (57, 58, or 59)
   3.

   Check about:support
   1.

  Down in the “Accessibility” section, is “Activated” true? And,
  2.

  Do you experience performance degradation?
  3.

  If so, please contact jmathies and/or davidb.


If you are aware of friends or family that have experienced bad performance
on Firefox 57 for Windows please also contact us. In particular, if they
solved their problem by disabling accessibility these are exactly the
systems from which we need to gather more info.

Thanks,

Jim and David
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

ARIA implementation plans (was Re: W3C Proposed Recommendations: WAI-ARIA and Core Accessibility API Mappings)

[David Bolter]

Hi Tantek,

I spun this off the rec proposals thread as per your suggestion.

On Thu, Nov 30, 2017 at 8:58 PM, Tantek Çelik 
wrote:

> On Thu, Nov 30, 2017 at 4:10 PM, L. David Baron  wrote:
>
>
[snip]


> Two things:
>
> 1. Do we have an Intent to Implement / Ship for the full testable
> feature set of these specifications? (I couldn't find any such
> "Intent" "ARIA" emails in dev-platform, but I may have missed it).
> If not, could the implementing team please send after-the-fact
> either/both Intent to Implement / Intent to Ship emails for both specs
> to dev-platform?
>

This work is unscheduled and TBD but we will send an intent when ready. The
accessibility team has been explicitly deprioritized working on new ARIA
support until the Windows multiprocess accessibility support work is in
good shape, our priority backlog is addressed, and priority front end work
is done.

Nonetheless, Joanie (chair of W3C ARIA spec) has been implementing some
ARIA recently in Firefox!



>
> 2. Assuming we have such intent, do we have bugs filed in Bugzilla to
> implement the remaining testable features of both specifications?  (to
> get the following %s to 100)
>

Not exhaustively no (for similar reasons)


> From Core Mappings report above:
> Firefox on Linux using ATK: 79% of mappings successfully implemented
> (188/237)
> Firefox on macOS using AX API:: 41% of mappings successfully
> implemented (84/205)
> Firefox on Windows using MSAA + IAccessible2: 75% of mappings
> successfully implemented (181/242)
> (or do we have documented somewhere reasoning why we won't implement
> to 100% - and if so, do we have problems with some of the features?)
>
> From WAI ARiA report above:
> no % tallies provided, but lots of red and yellow squares in the FF**
> columns here:
> https://w3c.github.io/test-results/wai-aria/all.html
>
>
It will be really great to get to a place where turning these green gets
back into our top priorities, unfortunately we're not there yet.



> Feel free to follow-up to this part (re: specs that we implement) with
> a reply-with-subject-change to start a new thread as needed.
>
> Thanks,
>
> Tantek
>

Thanks for your detailed attention here!

Cheers,
David
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: W3C Proposed Recommendations: WAI-ARIA and Core Accessibility API Mappings

[David Bolter]

Hi Jonathan,

On Thu, Nov 30, 2017 at 9:23 PM, Jonathan Kingston  wrote:

>
> *Thoughts*
> We should ensure ARIA provides clear justification for any other roles that
> already have HTML representation.
> I'm pretty sceptical of ARIA helping Accessibility. I think there is more
> impact when assistive and non-assistive improvements work together like
> .
>
>
I definitely agree with the impact part. But as long as web developers are
able to build a dialog out of divs and spans, at least there is a way to
give that jumble a role. The use of ARIA should be a smell* yes, but it has
been essential to making what exists out there accessible.

* the problem is either: the web dev has reinvented something that would
have hasd baked-in accessibility had they followed best practice instead,
Or, best practice doesn't yet cover what web apps want or need to do...
(related, see rules here https://www.w3.org/TR/using-aria/#rule1)

Cheers,
D
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

IMEs can instantiate accessibility (was Re: INTENT TO DEPRECATE (taskcluster l10n routing))

[David Bolter]

On Mon, Dec 4, 2017 at 8:58 AM, Axel Hecht  wrote:

> Am 04.12.17 um 05:42 schrieb Jet Villegas:
>
>>
>> On Sun, Dec 3, 2017 at 05:15 Axel Hecht > l...@mozilla.com>> wrote:
>>
>> Am 01.12.17 um 16:45 schrieb Justin Wood:
>> > Hey Everyone,
>>
>>
[snip]

I hope we can change that (testing on localized builds) with this proposed
>> change. We’ve gotten reports that localized builds (and related usage;
>> e.g., input method editors) cause A11y API activation, which triggers other
>> bugs for us.
>>
>
> My gut reaction is "that shouldn't happen", though, well, no idea what
> IMEs do. Do we have bugs tracking these? I'd love to be on CC on those.
>

It can happen. IMEs often have prediction features and they need to examine
the context under which the input is happening. One example we recently
learned of is a Japanese IME feature ATOK's "insight" which analyzes
focused web content for input prediction and switching dictionaries.

The main side effect is performance.

We need to do two things here:
1. Add more caching to our Windows e10s a11y solution.
2. Do something smart about the different kinds of clients that instantiate
a11y. This will likely be two things: blocking 'a11y' clients who that are
just being ridiculous, and better, copying what Chrome does and instantiate
only 'portions' of our a11y support... think of this as having a
'lightweight' mode, although it may be that we have multiple levers.

Cheers,
D
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: Retained Display Lists (rollout plan)

[David Bolter]

Hi All,

Retained Display Lists (RDL) will be enabled for release-channel users in
Firefox 61, with a gradual rollout [1].

   - RDL will be initially disabled for all users, then 2 days after FF61
   go-live, we push RDL to 25% of users.
   - We then monitor for a week, then push RDL to 50% of users.
   - After that week, we then push RDL to 100% of users.

Please reply if you have any questions or concerns about this plan.

Thanks,

David and Matt

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1467514
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: ARIA membership and role="password"

[David Bolter]

Hi Johnathan,

Our lack of direct W3C ARIA involvement recently is mainly due to
time/resource constraints and we have influence via proxy.

I think ARIA is best scoped as passive semantics used to describe the
reality of how web developers (ab)use HTML. It is not unreasonable to argue
that ARIA, by existing, implicitly condones this (ab)use. That said, we
made the decision a long time ago to advocate using proper semantic HTML
(and evolve HTML where it falls short), while accepting the need for a
solution/hack for the reality of what web developers are doing.

The password case is interesting though I've not followed it closely. I'm
happy to connect you with people (including Rich) if needed (feel free ping
me offline)...

Cheers,
D

On Thu, Jun 2, 2016 at 8:55 AM, Jonathan Kingston 
wrote:

> 
> Hey,
>
> So I was just informed that Mozilla isn't a member of the ARIA working
> group which shocked me, we have however had a hand in the spec over the
> years (I have cc'd those mentioned).
>
> I notice over the years some disappointment with the spec as it being a
> separate module to semantics in HTML itself however I don't see a real
> opposition not to be in the group. This seems more of a formality when the
> group split into two working groups.
>
> It appears that ARIA 1.1 is moving to be resolved in the next few weeks so
> if we had any objections we would need to move now I have been told.
>
> *role="password"* has been added to the spec:
> https://rawgit.com/w3c/aria/master/aria/aria.html#password and I jotted
> my objections in a post:
> https://jotter.jonathankingston.co.uk/blog/2016/05/16/role-password-is-not-wise/
>
> My post was largely dismissed in this mail:
> https://lists.w3.org/Archives/Public/public-aria/2016May/0126.html
>
> Is it worth us joining? Can we discuss the wider use of ARIA itself?
> Rushing to standardise features seems a shame.
>
> Thanks
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: W3C Proposed Recommendations: WAI-ARIA (accessibility)

[david bolter]

I support this W3C Recommendation.

Cheers,
David

On Tue, Feb 11, 2014 at 2:22 PM, L. David Baron  wrote:

> W3C recently published the following proposed recommendations (the
> stage before W3C's final stage, Recommendation):
>
>   Accessible Rich Internet Applications (WAI-ARIA) 1.0
>   http://www.w3.org/TR/2014/PR-wai-aria-20140206/
>
>   WAI-ARIA 1.0 User Agent Implementation Guide
>   http://www.w3.org/TR/2014/PR-wai-aria-implementation-20140206/
>
> There's a call for review to W3C member companies (of which Mozilla
> is one) open until March 7.
>
> If there are comments you think Mozilla should send as part of the
> review, or if you think Mozilla should voice support or opposition
> to the specification, please say so in this thread.  (I'd note,
> however, that there have been many previous opportunities to make
> comments, so it's somewhat bad form to bring up fundamental issues
> for the first time at this stage.)
>
> -David
>
> --
> 𝄞   L. David Baron http://dbaron.org/   𝄂
> 𝄢   Mozilla  https://www.mozilla.org/   𝄂
>  Before I built a wall I'd ask to know
>  What I was walling in or walling out,
>  And to whom I was like to give offense.
>- Robert Frost, Mending Wall (1914)
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Input Delay Metric proposal

[David Bolter]

[cc+ Heather for perceived performance]

Hi Randell,

I think I like this and I'm glad you are thinking about it. Measuring time
between TTI and FCP seems useful to me. You touched on a bunch of my
questions in the Issues section and I don't have answers but others might?
:)

Cheers,
David



On Wed, Sep 19, 2018 at 2:45 PM Randell Jesup  wrote:

> Problem:
> Various measures have been tried to capture user frustration with having
> to wait to interact with a site they're loading (or to see the site
> data).  This includes:
>
> FID - First Input Delay --
> https://developers.google.com/web/updates/2018/05/first-input-delay
> TTI - Time To Interactive --
>
> https://developers.google.com/web/fundamentals/performance/user-centric-performance-metrics#time_to_interactive
> related to: FCP - First Contentful Paint and FMP - First Meaningful Paint
> --
>
> https://developers.google.com/web/fundamentals/performance/user-centric-performance-metrics#first_paint_and_first_contentful_paint
> TTVC (Time To Visually Complete), etc.
>
> None of these do a great job capturing the reality around pageload and
> interactivity.  FID is the latest suggestion, but it's very much based
> on watching user actions and reporting on them, and thus depends on how
> much they think the page is ready to interact with, and dozens of other
> things. It's only good for field measurements in bulk of a specific
> site, by the site author.  In particular, FID cannot reasonably be used
> in automation (or before wide deployment).
>
> Proposal:
>
> We should define a new measure based on FID name MID, for Median Input
> Delay, which is measurable in automation and captures the expected delay
> a user experiences during a load.  We can run this in automation against
> a set of captured pages, while also measuring related values like FCP
> and TTI, and dump this into a set of per-page graphs (perhaps on
> "areweinteractiveyet.com" :-) ).
>
> While FID depends on measuring the delay when the user *happens* to
> click, MID would measure the median (etc) delay that would be
> experienced at any point between (suggestion) FCP and TTI.  I.e. it
> would be based on "if a user input event were generated this
> millisecond, how long would it be before it ran?"  This would measure
> delay in the input event queue (probably 0 for this case) plus the time
> remaining until he current-running event for the mainthread finishes.
>
> This inherently assumes we measure TTI and FCP (or something
> approximating it).  This is somewhat problematic, as TTI is very noisy.
> I have a first cut at TTI measurement (fed into profiler markers) in
> bug 1299118 (without the "no more than 2 connections in flight" part).
>
> Value calculation:
> Median seems to be the best measure, but once we have data we can look
> at the distributions on real sites and our test harness and decide what
> has the most correlation to user experience.  We could also measure the
> 95% point, for example.  In automation, there might be some advantage to
> recording/reporting more data, like median and 95%, or median, average,
> and 95%, and max.
>
> Another issue with the calculation is that it won't capture burstiness
> in the results well (a distribution would).
>
> Range measured over:
> We could modify the starting point to be when the first object that
> could be interacted with is rendered (input object, link, adding a key
> event handler, etc).  This would be a more-accurate measure for web
> developers, and would matter only a little for our use.  Note that
> getting content on the screen earlier might in some cases hurt you by
> starting the measurement "early" when the MainThread is presumably busy.
>
> Likewise, there might very well be alternatives to TTI for the end-point
> (and on some pages, you never get to TTI, or it's a Long Time).  Using
> TTI does imply we must collect data until 5 seconds after the last "Long
> Task", and since some sites will never go 5 seconds without a long
> task, we'll need to upper-bound it (or progressively reduce the 5
> seconds over time, which may help).   Alternatively, we could use a
> shorter window, or put an arbitrary limit on it (5 seconds past
> 'loaded', or just to 'loaded'), etc.
>
> Issues:
>
> Defining the start and stop point, and the details around the exact way
> we calculate the result (I hand-wove about it above).  Note that
> "longer" endpoints will result generally in better scores, since it
> would average over probably a longer tail where less is happening
> (presumably).  OTOH if it ends at TTI on a "Long Task" (50+ms event),
> that rather implies that it was at least intermittently busy until then.
>
> If we want to start when something interact-able is rendered, there may
> be some work to figure that out.
>
> Note that this inherently is measuring the delay until the input event
> *starts* processing, not how long it takes to process (since there is no
> actual input event here).
>
> Once we have some experience with this

Re: [ann] Slides from Mozilla Android Bootcamp presentation

[David Bolter]

Thank you Nick! This is going to be an enduring resource!
D

On Sat, Jul 6, 2019 at 5:34 PM Nicholas Alexander 
wrote:

> On Wed, Jun 26, 2019 at 10:08 AM Nicholas Alexander <
> nalexan...@mozilla.com>
> wrote:
>
> > Hello all,
> >
> > On Wed, Jun 19, 2019 at 10:19 AM Nicholas Alexander <
> > nalexan...@mozilla.com> wrote:
> >
> >> Hello folks,
> >>
> >> As part of the June 2019 Whistler All Hands
> >> , I delivered a
> >> presentation titled "Android Bootcamp" for Gecko/platform engineers
> working
> >> on Android.  It's a 10,000 foot view of Mozilla's Android ecosystem and
> how
> >> to get started building and running Gecko and GeckoView on Android.
> >>
> >> Here are the publicly available slides
> >> <
> https://docs.google.com/presentation/d/1MzU9q2wCwojC0kb1eVfma8hrQ-KayCRFFd_mV5Gx1F4/edit#slide=id.g37695b23f5_0_10
> >
> >> .
> >>
> >
> > Many people reached out to inform me that the slide footer said "Mozilla
> > Confidential".  Nothing here is confidential and I have removed the
> > footer.  Sorry for the confusion, and many thanks to the folks who
> informed
> > me of the footer.
> >
> >
> >> The session was videotaped and I am told it will be available on
> >> air.mozilla.org but I don't know when it will be posted.
> >>
> >
> > It is available on air.mozilla.org now:
> >
> https://onlinexperiences.com/Launch/Event.htm?ShowKey=44908&DisplayItem=E333861
> ,
> > but I think that the recording is private to Mozilla.  The quality of the
> > recording is not great -- somebody kept walking in front of the projector
> > -- so I intend to record a webinar version.  More if and when I get to
> it!
> >
>
> I did get to recording a webinar version
> .  It
> can be viewed from Google Drive directly or downloaded (roughly 2Gb at a
> high quality).  This webinar version should be viewable by anybody with the
> link.
>
> I recorded in a sound booth at the Vancouver Public Library so the audio
> track is great but the video background is not great.  There were some good
> questions raised at the end of the Whistler session but I ran out of time
> when recording so they're not included in the webinar version.
>
> Best,
> Nick
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform