Intent to Implement and Ship: , reflected by HTMLLinkElement.disabled
Summary: Make the disabled attribute on link elements do something useful, and the disabled IDL attribute reflect this attribute instead of forwarding to the style sheet object (if present). This is mostly compat work, but should also do less work in pages that use it already. See below for the long story. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1281135 Link to standard: https://github.com/whatwg/html/pull/4519 There are two parts of this proposal. One is "implementing the disabled attribute". That's what that HTML spec PR is about. The other is about changing the behavior of HTMLLinkElement.disabled, which we do implement, to reflect the content attribute. This used to be spec'd like what Gecko does, but was removed from the spec. New thing matches WebKit / Blink. See the "Do other browser engines implement this?" for all details you may want to know (and probably more) about this situation. Platform coverage: All Estimated or target release: 68 Preference behind which this will be implemented: dom.link.disabled_attribute.enabled Is this feature enabled by default in sandboxed iframes? Yes DevTools bug: I don't think it's needed, but please file if you think otherwise. Do other browser engines implement this? All other engines implement the disabled attribute in one way or another. See below for the details of what WebKit and Blink do. Edge looks like they implemented the `disabled` attribute as a "default value for the stylesheet disabled flag" kind of thing. That has the downside of still downloading the stylesheet in a case where WebKit and Blink don't right now, and thus I don't think WebKit or Blink would be interested in switching to such a model. Regarding HTMLLinkElement.disabled, also all engines implement it, with two different behaviors right now: * Gecko (before my patch) and Edge implement the old spec for this, where it forwards to the stylesheet's disabled flag. * Blink / WebKit implement it as reflecting the disabled attribute (I'm not aware of any spec reference, historical or not, for this behavior, but I'd be interested in knowing about it). Now the long story, which is mostly in [1]. The TL;DR: is written in [2], and that contains the proposed behavior that my change implements. Feel free to skip to the "web-platform-tests" section below if you're not interested on the details. Blink and WebKit implement the `disabled` attribute on stylesheets, and it's the only way to enable alternate stylesheets there. There's no spec for that of course, and the behavior of this attribute in those engines is quite bizarre (see [1] for reference). Separately, there's the HTMLLinkElement.disabled setter and getters, which were removed from the spec, but that everyone still implements (and I'm pretty sure it'd not be compatible to remove it). Spec-wise, the spec says that alternate stylesheets are supposed to be implemented using the disabled flag on the stylesheet [3]. Edge and Gecko do that, and make HTMLLinkElement.disabled forward to the stylesheet. In WebKit / Blink, this is not the case. An alternate stylesheet is not disabled (as in `link.sheet` is non-null, `link.sheet.disabled` returns false, but still magically does not apply to the page). The only way to enable such an stylesheet in Blink and WebKit is removing the `disabled` attribute on the link. This means that the only way to have a cross-browser alternate stylesheet is: And the cross-browser way to enable is using `link.disabled`: * In Gecko and Edge, that setter will forward to the stylesheet, object (it's the same as saying `if (link.sheet) link.sheet.disabled = false;`. And given they implement alternate sheets according to the standard, then it'd enable the already loaded and parsed stylesheet. * In Blink and WebKit, this will remove the disabled attribute, which will load the stylesheet, and set a magic "explicitly enabled" bit that will make the stylesheet apply when it loads. Separately, some websites are starting to use: And it's a common cause of confusion when people find that it doesn't work on Firefox. The disabled attribute on its own does nothing in Gecko and thus we apply the stylesheet when other browsers don't, and thus the website breaks. This is all quite sad and bizarre, and other that this move I don't see many other paths forwards to achieve interop in all this mess. Blink and WebKit could probably fix their alternate stylesheet implementation to properly use the disabled flag, but given their use counters [4][5] they'll probably not remove the disabled attribute regardless. Also, they have other incentives to keep the disabled attribute, like the fact that for them it's a performance boost (they don't have to download and parse potentially large stylesheets). So my proposed model aligns with WebKit and Blink as much as possible without implementing obvious bugs. The disabled attribute also causes the stylesheet to not be present / loaded at all. This makes sense, and
Intent to implement & ship: Document.cookie
Hi everyone, *Summary*: I'm planning to move the cookie attribute from HTMLDocument to Document to bring our implementation of this attribute on par with the HTML spec. *Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=144795 *Link to standard*: https://html.spec.whatwg.org/multipage/dom.html#the-document-object *Platform coverage*: all platforms. *Estimated or target release*: Firefox 68. *Preference behind which this will be implemented*: No preference. *Is this feature enabled by default in sandboxed iframes?* The attribute is available to all frames, abiding by the existing sandbox restrictions guarding the visibility of cookies. *DevTools bug*: No specific devtools support needed. *Do other browser engines implement this?* Yes, both Blink and WebKit support Document.cookie since a long time ago. In fact this is motivated by eliminating a wpt test failure that only fails in Firefox. *web-platform-tests*: This fix makes us pass the existing wpt tests that test for the availability of the cookie attribute on various non-HTML documents. *Is this feature restricted to secure contexts?* No. This is motivated by improving our web compatibility story, so we'd like to make this attribute available where other web engines already make it available. Thanks, -- Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: A note on how we will manage updates to Phabricator
> On Apr 17, 2019, at 15:22, Dylan Hardison wrote: > > Phabricator upgrades will happen every Monday between 14:00 and 13:00 UTC. There is no time travel involved, rather this is an error from rewriting the time from 12hr time to 24hr time. The window is 14:00 to 15:00 UTC. Regards, - Dylan Hardison Engineering Workflow, Time Travel division. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
A note on how we will manage updates to Phabricator
Phabricator upgrades will happen every Monday between 14:00 and 13:00 UTC. Upgrades usually have no visible impact on the user; however, some updates may cause Phabricator to be partially unavailable during this window. Because of the way Phabricator handles database schema migrations, we expect downtime when the schema changes. Not every release includes schema changes, and most of them happen quickly. Sometimes schema changes could take nearly an hour, hence the 1 hour window. This schedule was chosen based on the following constraints: Predictable maintenance windows are less disruptive than ad-hoc ones. The Phabricator upstream project updates once a week and our team maintains some extensions on top of it. Weekly updates are desirable to get features and bug fixes into production rapidly. There is no ideal time for any downtime given that Mozilla is a distributed organization. If you have any questions about this, we’re available in #phabricator on slack for any questions and concerns. Regards, Dylan Hardison Engineering Workflow Team. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Lack of browser mochitests in non-e10s configuration and support for turning off e10s on desktop going forward
Hello, Today it came to my attention that there are no 1proc (non-e10s) browser mochitests running anymore. It appears they were disabled in https://bugzilla.mozilla.org/show_bug.cgi?id=1433276 in early 2018, which is somewhat odd because it looks like the bug talks about linux32, but removed the win7 non-e10s browser chrome tests. At the time, linux64-jsdcov was still non-e10s, but that was changed in https://bugzilla.mozilla.org/show_bug.cgi?id=1451849, a bit later in 2018 . This was a surprise to me because there is still a bunch of in-tree desktop browser frontend code that is supposed to work if e10s is turned off using the relevant pref. But we apparently have no automated test coverage for this [so one assumes that some of it does not, in fact, work anymore...]. The last discussion about e10s test support that I'm aware of dates back to 2017. I do not recall there being public discussion about turning off these tests when it did happen (though of course, being human, it's possible I missed or forgot about it). I'm aware we still turn off e10s on esr60 in some circumstances, and that on other channels the hidden pref can be used to do the same. Open questions that I'd like to ask: 1. do we still consider running desktop Firefox with e10s disabled a supported configuration? 2. Will we need to turn it off on esr68 in the same circumstances where that happens on esr60? 3. If the answer to either of the previous 2 questions is 'yes', do we think it's acceptable not to run desktop tests on the configuration? 4. If the answer to both (1) and (2) is 'no', can we remove support for the pref and running desktop Firefox without e10s ? Some of the codepaths are not unified and so there is effectively dead code that we're lugging around for what would be no reason. (Note: a significant proportion isn't dead because even in e10s, we load some browser-provided content in parent process, ie a tab's browser is not always remote/non-same-process -- but even so, there's a bunch of stuff that keys off gMultiProcessBrowser that could be removed.) Thanks, Gijs ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
