Re: Intent to implement and ship: add `preventScroll` option to HTMLElement's, SVGElement's and XULElement's `focus` method
On Monday, April 15, 2019 at 9:21:57 AM UTC+2, Makoto Kato wrote:
> Hi, Mirko. (I mistake email address. sorry)
>
> Does this work on GeckoView/Android too? When showing software keyboard,
> web page may be scrolled without focus manager.
For the record: GeckoView will need to be adapted separately. There's
https://bugzilla.mozilla.org/show_bug.cgi?id=1544660 to achieve this.
>
> -- Makoto
>
> On Thu, Apr 11, 2019 at 11:35 PM Mirko Brodesser
> wrote:
>
> > *Summary*: this allows web-developers to focus an element without scrolling
> > to it.
> >
> > *Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1374045
> >
> > *Link to standard*:
> > https://html.spec.whatwg.org/#dom-focusoptions-preventscroll
> >
> > *Platform coverage*: all platforms.
> >
> > *Estimated or target release*: Firefox 68.
> >
> > *Preference behind which this will be implemented*: not applicable.
> >
> > *Is this feature enabled by default in sandboxed iframes?* No and there's
> > no new sandbox flag to enable it.
> >
> > *DevTools bug*: none.
> >
> > *Do other browser engines implement this?* Shipped in Chrome (since version
> > 64).
> >
> > *web-platform-tests*:
> >
> > http://w3c-test.org/html/interaction/focus/processing-model/preventScroll.html
> >
> > *Is this feature restricted to secure contexts?* No.
> >
> > *How stable is the spec: *it seems stable, apart from the special case of
> > re-focusing an element: https://github.com/whatwg/html/issues/4512.
> >
> > *Example:* data:text/html, input { margin-top: 40cm }
> > document.getElementById("i1").focus({
> > preventScroll: true });
> >
> > The feature is planned to be shipped with Firefox 68. Chrome has already
> > shipped it.
> >
> > *Bug to turn on by default*:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1374045
> >
> > If there are questions or suggestions, please let me know.
> > ___
> > 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: PSA: web-platform-tests (dashboard | fuzzy-reftests | reftest comparisons)
On Mon, Apr 15, 2019 at 7:16 PM Jonathan Watt wrote: > These are all really great. Thanks, James! Indeed, thanks a lot for working on this! This will help a lot with prioritizing work and also with standards development. Some feedback for the Interop Dashboard: * It would help me a bit if it clarified which versions of Chrome, Firefox, Safari are represented to make local comparisons more easily. * It would also be nice to be able to give a wpt path rather than have to find the corresponding bug component. * I don't see all the bug components, e.g., DOM::Core: Networking is missing. Kind regards, Anne ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to remove "-e10s" from treeherder group symbols and task labels
This has now landed. So to re-iterate, if you see a "-1proc" suffix in the task symbol that means it is running with e10s disabled. Otherwise e10s is enabled. This symbol change will ride the trains (so you'll still see "-e10s" on other branches for the time being). On Wed, Apr 10, 2019 at 9:40 AM Andrew Halberstadt wrote: > I had about 5 independent suggestions of "-sp" and I agree that it is much > better than "-fc". But another idea that came out of these conversations > was "1proc" which also ticks all the boxes (only being a tiny bit longer > than "e10s") and being even clearer than "-sp". I think I'll go with that > one. Thanks to everyone for all the feedback! > > -Andrew > > On Wed, Apr 10, 2019 at 4:36 AM Jonathan Kew wrote: > >> On 09/04/2019 20:44, Andrew Halberstadt wrote: >> > Yeah, I did consider "non-e10s" for awhile and maybe it is the better >> > choice. But here are my counter arguments: >> > >> > 1) One of the goals of this change is to de-clutter the treeherder UI. >> > Using an 8 character symbol suffix runs counter to that goal (even if >> it is >> > still less cluttered overall). >> > 2) People who use "e10s" in their |mach try fuzzy| queries out of muscle >> > memory (or in saved presets) will accidentally select the exact >> opposite of >> > what they want. >> > 3) For new contributors "e10s" is a code word anyway. It's just now they >> > need to learn "fc" instead of "e10s". >> > >> > None of those are terribly compelling, but it's still enough to make me >> > prefer "-fc". >> >> I think (1) and (2) here are good points; I'm less convinced by (3). >> Yes, e10s is a code word, but it's one that is pretty long-established >> and pervasive in the project and surrounding documentation (it even >> shows up in the names of about:config settings). It appeared in >> treeherder UI *because* it was a well-established term within the project. >> >> The proposed -fc suffix, on the other hand, seems gratuitously cryptic. >> If it had suddenly appeared in treeherder, I'd have been totally >> clueless as to its meaning; and even after seeing the announcement here, >> it feels like an artificial label that's trying a bit too hard to come >> up with a "clever" code where none is needed. It's not like we're >> starting with a standard multi-process configuration, and launching a >> grand "Fuel Cell" project that aims to merge the processes together. >> >> How about suffixing these jobs with -sp for "Single Process"? That would >> be a lot more transparent, IMO. >> >> JK >> ___ >> 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
Intent to unship: XMLDocument.load and XMLDocument.async APIs
Hi everyone, As of Firefox 68 I'm planning to turn off support for non-standard XMLDocument.load and XMLDocument.async APIs. These are really old APIs that allow developers to load an XML document over the network synchronously or asynchronously but were never standardized and implemented by other web engines, and have long been replaced by XMLHttpRequest. On Beta65, XMLDocument.load() is being used on ~0.003% of top level page loads (see UseOfDOM3LoadMethod in https://georgf.github.io/usecounters/index.html#kind=page&group=DEPRECATED&channel=beta&version=65) and the setter of XMLDocument.async is used on ~0.009% ( https://georgf.github.io/usecounters/index.html#kind=page&group=XMLDOCUMENT&channel=beta&version=65). These numbers are a bit surprising since it looks like about three times as many pages set the async attribute without calling load() but setting async without calling load() has no side effects... We believe the usage is low enough to try to unship, but we're not yet removing the code. The unshipping is done by hiding both APIs behind a pref in https://bugzilla.mozilla.org/show_bug.cgi?id=332175 and https://bugzilla.mozilla.org/show_bug.cgi?id=1328138. Please let me know if you have any questions or concerns. Thanks, -- Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: web-platform-tests (dashboard | fuzzy-reftests | reftest comparisons)
On 16/04/2019 12:17, Anne van Kesteren wrote: On Mon, Apr 15, 2019 at 7:16 PM Jonathan Watt wrote: These are all really great. Thanks, James! Indeed, thanks a lot for working on this! This will help a lot with prioritizing work and also with standards development. Some feedback for the Interop Dashboard: * It would help me a bit if it clarified which versions of Chrome, Firefox, Safari are represented to make local comparisons more easily. In general we are always using the latest experimental versions available for the platforms we have (Firefox Nightly / Linux, Chrome dev / Linux and Safari TP / macOS). The wpt.fyi link should have more details about the specific versions used for the currently loaded run; I could add that somewhere in the dashboard if it's helpful. * It would also be nice to be able to give a wpt path rather than have to find the corresponding bug component. It's not the best UI but you can select "Any" as the bug component and then filter by path. That does end up loading all the data though. Allowing to select by either component or path at the top level would be a larger change, but it's certainly possible if people would find it useful. The idea of making component the top-level selector was to enable workflows analogous to bug triage where the work is divided up by component. * I don't see all the bug components, e.g., DOM::Core: Networking is missing. The mapping from component to test directories is in testing/web-platform/moz.build Per that file there aren't any tests covering DOM::Core: Networking. More likely the component to path labels contain some errors that should be fixed. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
