Re: Intent to Prototype: Aliasing -webkit-font-feature-settings to font-feature-settings for webcompat
Hi Jens, On 8/31/20 10:02 AM, Jens Hausdorf wrote: Hi everyone! Summary: Aliasing the proprietary css property -webkit-font-feature-settings to font-feature-settings so Gecko picks up more CSS stylesheets, eventually producing the same behavior as with Webkit for website that don't update their css to include the standardized version of font-feature-settings. Thank you for working on this! -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: CSS subgrid
Hi David, On 10/21/19 7:22 AM, L. David Baron wrote: (That we haven't applied the policy that much because we've granted exceptions because other browsers have shipped the features reduces the effectiveness of the policy and its ability to meet its goals. This is the sort of policy that is most effective if it applies to the largest number of thngs, both because it has larger effects and because it sets much clearer expectations about what will be limited to secure contexts. I think it's worth considering reducing that exception to the existence of actual web compat problems from the secure contexts limitation.) Can you unpack this a little here? Are we saying we would ship features in non-secure contexts because sites theoretically rely on that behavior due to another browser shipping as non-secure before we did? (This sounds like the current rationale for exceptions, I think). Or are we saying we would ship a feature by default as secure and be willing (compelled?) to move to non-secure if we discover sites rely on other significant market share browsers not requiring a secure context for said feature -- once our users reported the bugs (or we did some kind of analysis beforehand)? Looking at <https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts#Secure_context_restrictions_that_vary_by_browser>, I'm trying to imagine what that would look like. -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [blink-dev] Re: What to do about scroll anchoring?
Hi Rick, On 9/28/19 10:07 PM, Rick Byers wrote: Can you give us a week or so to chat about this within the Chrome team and get back to you? Any updates here? Thanks. -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Remove browser and OS architecture from Firefox's User-Agent string?
On 5/21/19 12:45 AM, Henri Sivonen wrote: On Tue, May 21, 2019 at 12:40 AM Randell Jesup wrote: I wonder if any sites distributing windows executables might key off the OS version to default to the correct exe for your version of windows? Are there known examples of apps like that? AFAICT, even Skype.com provides the Windows 7 -compatible .exe as the download even with a Windows 10 UA string, and you need to know to go to the Store if you want the Windows 10-only version. A while back I tried to hit up a bunch of software download sites and wasn't able to find anything to answer this question. At best, I think the answer is maybe? I wonder if PI could help us with this type of thing. -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Remove browser and OS architecture from Firefox's User-Agent string?
On 5/14/19 12:53 PM, Tom Ritter wrote: On Tue, May 14, 2019 at 4:26 PM L. David Baron wrote: So I think there's may be value in removing these distinctions from the User-Agent header we send over HTTP even if they're still accessible from Javascript (and useful there for sites offering downloads). While I would prefer to remove the distinction everywhere; Tor Browser came to this same conclusion. They send the same OS for all platforms in the HTTP Header (partially because Web Logs so commonly record this and partially in principal) but they report the correct OS via javascript (because we found issues with compatibility (primarily keyboard shortcuts in things like gdocs.) That's interesting -- do you have links to bugs? thanks, -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to unship: typeMustMatch attribute on elements
On 5/3/19 4:06 AM, Frederik Braun wrote: In bug 1548773, annevk suggested to unship the `typeMustMatch`attribute from elements[1]. No other browser supports this and we have just learned that this attribute can be used to leak information about cross-origin resources[2]. While it seems worth removing immediately to me, I'm interested in additional feedback. I ran a search on BigQuery over HTTP Archive data (just for desktop) and here are the results: <https://docs.google.com/spreadsheets/d/1z9-QVOqZtTJ1LcpSfjrW8CdoHHTrAaktiOjr7NJ_mgE/edit#gid=344963178> I only looked at 10 random items, and nothing seemed alarming -- just enumeration of attributes, or mapping strings to props, or regular expressions looking for valid attributes. (Might be worth someone putting in more than 5 minutes of poking around though). -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Improving our usage of Bugzilla
On 3/12/19 12:53 PM, Kohei Yoshino wrote: The User Story field will be soon removed from the new bug page. https://bugzilla.mozilla.org/show_bug.cgi?id=1525376 The User Story has been used to track which domains should be added to the Disconnect lists for a huge pile of tracking protection bugs (see most of the bugs in the https://bugzilla.mozilla.org/show_bug.cgi?id=1101005 dep tree). If this field goes away, will that information be lost? -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: aligning with the spec on document.open behavior and removing wyciwyg
On 2/22/19 4:14 PM, Boris Zbarsky wrote: There is a certain amount of compat risk here, since this is changing a very longstanding behavior. I'm hoping that by aligning with the spec (except for a few edge cases like calling document.open() on a document whose iframe has been removed from the DOM that we used to no-op and continue to no-op) and other browsers we keep the risk pretty low. I appreciate the efforts here -- this will also fix a class of compat bugs in itself. It will be interesting to see what, if anything pops up in terms of bustage. -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to unship: LocalMediaStream
On 10/11/18 11:13 AM, Andreas Pehrson wrote: We don't have telemetry for this. On the other hand we're the last ones still implementing this, so that takes care of the people that don't test in Firefox that you mention. FWIW Chrome removed this in 47. That's three years ago. And Chrome tends to be what most services develop and test against when it comes to webrtc (with its still actively changing spec). https://bugs.chromium.org/p/chromium/issues/detail?id=338500 In light of this, do you still think we need to add telemetry? I think if Chrome was able to successfully remove, there's a lot less risk. -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to unship: LocalMediaStream
On 10/11/18 9:16 AM, Andreas Pehrson wrote: I would like to unship the MediaStream subclass LocalMediaStream and its stop method. Firefox is the only major browser to still ship LocalMediaStream. It is the type we use for the MediaStream that is returned from getUserMedia. The most breakage I expect is for the removal of the stop method, but for this we shipped a console deprecation warning in Firefox 44 (bug 1103188). Do we have telemetry on usage of stop? If not, can we collect it? In my experience, developers aren't really paying attention to deprecation warnings in the console (...especially the ones that don't test in Firefox). -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to unship: mozAutoGainControl & mozNoiseSuppression constraints (and AGC=on by default)
Hi Jan-Ivar, On 10/10/18 9:48 AM, Jan-Ivar Bruaroey wrote: The most likely net fallout of, if any, would be sites that UA-sniff AND rely on the legacy Firefox names ONLY to turn OFF audio processing. These are likely to be specialty sites dealing with things like music rather than your typical WebRTC communication site. More likely, old sites would double up the moz and non-moz constraints here in order to work with both Firefox and Chrome, and in those cases, there is no impact. If they didn't include an unprefixed constraint, would it throw? thanks, -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: User Agent Strings in Firefox and their history
Hi Eric, On 9/20/18 11:21 AM, Eric Shepherd (Sheppy) wrote: We actually have a page on MDN about this kind of thing already: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox. If you would like to update or redo that page with your new work, that would be incredibly excellent. Yeah, thanks for the pointer - I've contributed to that document over the years. I'm not sure the level of detail I'm aiming for is appropriate for that general purpose page, but there's an opportunity to improve the existing MDN page for sure. thanks, -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
User Agent Strings in Firefox and their history
Hi, For the past few weeks I've been working on a reference document [1] for UA strings in Firefox products, and how they've changed since Firefox 4. If anyone is interested in these types of things (there's dozens of us), and would like to review it and perhaps point out mistakes or things I've missed, that would be cool. At some future point it can get moved from a Google doc to a wiki, or MDN or maybe medium.com (kidding). It should be set up so anyone with the link can add a comment. [1] <https://docs.google.com/document/d/1cizvn4wahdfwHUVG_H_Uf15HPBTWyB6GH7j_utHdrKc/edit?usp=sharing> thanks, -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: accept arbitrary webkit-prefixed pseudo-element in selectors
Hi Xidorn, On 9/5/18 3:35 AM, Xidorn Quan wrote: In Firefox 64, I intend to turn accepting arbitrary webkit-prefixed pseudo-element in selectors on by default on all platforms. It has been developed behind "layout.css.unknown-webkit-pseudo-element". WebKit and Blink have had this behavior for long. Thanks for working on this. Happy to have one less cause for busted sites in Firefox. -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship '-webkit-appearance' and changes to '-moz-appearance' values
Hi Jonathan, On 8/7/18 5:16 PM, Jonathan Watt wrote: Summary --- I plan to enable the pref in Nightly builds (using EARLY_BETA_OR_EARLIER) to turn on the '-webkit-appearance' alias for '-moz-appearance'. This pref simultaneously changes the behavior of the 'menulist-button' value, and shortly the 'button-bevel' value. Spec: None. We're reverse engineering Chrome and ignoring https://drafts.csswg.org/css-ui-4/#appearance-switching since the 'appearance' property defined there is not web compatible. From the "Possible ways forward" from that link, I think option 5 makes the most sense. We can always spec this in the Compat Standard, if the issue is never resolved. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1480073 Preferences: layout.css.webkit-appearance.enabled Platfrom coverage: All Estimated release: 63 (tentatively) Known webcompat impact: 19 out of 20 of the open -webkit-appearance webcompat.org issues are fixed by this change. This is very cool. Thanks for fixing sites for our users! We'll keep an eye out for weird regressions. -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Scrollbar color properties
> On Jul 9, 2018, at 6:31 PM, Xidorn Quan wrote: > > On Tue, Jul 10, 2018, at 7:36 AM, Tantek Çelik wrote: >>>> Platform coverage: Desktop >>> >>> Why not on mobile? >> >> Requires platform specific code that just hasn't been written (yet) >> for mobile platforms. > > Actually I don't really have a plan to support the rendering part of > scrollbar color properties on Android. Do you think we should have it? > > I don't see any evidence that scrollbar there is a problem for people on > mobile. People may want to hide the scrollbar at the end, but other than > that, scrollbar styling probably isn't something highly desired. I don’t have strong feelings — you’re right that we don’t have (known) compat issues related to scrollbar customization on mobile (and normally we don’t even see scrollbars). Unsure how important it is for other use cases, like mobile devices with styluses or mice (I believe we do see scrollbars then). But it seems like guessing at this point, since these properties haven’t shipped and sites don’t rely on them yet. -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Scrollbar color properties
Hi Tantek, > On Jul 9, 2018, at 4:36 PM, Tantek Çelik wrote: > > On Mon, Jul 9, 2018 at 1:57 PM, Mike Taylor wrote: >> Hi Xidorn, >> >>> On Jul 8, 2018, at 8:24 PM, Xidorn Quan wrote: >>> Hopefully with these properties (and one another controlling scrollbar >>> width or style to fulfill thin scrollbar usecases), WebKit and Blink would >>> be able to unship their current pseudo-elements, so that we wouldn't need >>> to implement them to get web compatible. > > Thanks Xidorn! > > >> I’m skeptical about this approach, given that it requires existing and >> legacy sites to update their code. But I would be happy to be wrong. ^__^ > > MS Edge disagrees as they have been able to *drop* their legacy > proprietary -ms- prefixed properties for scrollbar coloring (which was > often provided as a back-up in ::-webkit- scrollbar code samples) with > very little impact on apparent bugs / compat from their perspective. > > We confirmed this last week at the CSSWG meeting with MS Edge PMs. > Waiting on the official f2f minutes for a citation. That’s a very cool signal. > > >> To date the compat issues we care about (because they break layouts) are >> about assigning a specific width, or hiding the track entirely (via >> ::-webkit-scrollbar). > > Agree with the use-cases "specific width, or hiding the track > entirely" and the new (not yet implemented) scrollbar-width property > addresses those. > > https://drafts.csswg.org/css-scrollbars-1/#scrollbar-width > > Also we are getting strong informal signals (reconfirmed as of last > week) that there is high desirability to DROP the mess of > ::-webkit-scrollbar-* from existing implementations. This is a when > not if, and is largely waiting on sufficient proof of concept that CSS > Scrollbars solves enough use-cases to get at least some sites to > switch or provide both, which likely depends on us shipping the new > standard properties. > > Past evidence (which shows how this has changed to be even more > negative on webkit-scrollbars over the past year) until we get last > week's minutes: > > https://lists.w3.org/Archives/Public/www-style/2017May/0010.html > "smfr: It was a mistake to leak to web. We don't really like that > people can style scrollbars. We won't enhance and prefer to deprecate > it." > > https://lists.w3.org/Archives/Public/www-style/2017Dec/0040.html > "TabAtkins: We would like to drop as much of our weird -webkit- stuff > as possible." > ... > "smfr: We're interested only in very limited customization of > scrollbars. Would like to get rid of -webkit- scrollbar pseudo stuff. > smfr: we're only interested in coloring, and hiding scrollbars." > > Not quite an official intent to deprecate / unship, but clearly that's > the direction things are headed. Also positive signals. Typically Apple doesn’t drop support for anything that has shipped, at risk of breaking sites… so we’ll have to see how that evolves going forward. > > >>> Platform coverage: Desktop >> >> Why not on mobile? > > Requires platform specific code that just hasn't been written (yet) > for mobile platforms. > > Do you think this feature requires Desktop+Mobile parity/equivalency > before we ship on Desktop? Thanks. If we have plans to ship on mobile in the future, I would say no. I was mostly curious if this was considered as a “Desktop”-only feature. Thanks, -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Scrollbar color properties
Hi Xidorn, > On Jul 8, 2018, at 8:24 PM, Xidorn Quan wrote: > Hopefully with these properties (and one another controlling scrollbar width > or style to fulfill thin scrollbar usecases), WebKit and Blink would be able > to unship their current pseudo-elements, so that we wouldn't need to > implement them to get web compatible. I’m skeptical about this approach, given that it requires existing and legacy sites to update their code. But I would be happy to be wrong. ^__^ To date the compat issues we care about (because they break layouts) are about assigning a specific width, or hiding the track entirely (via ::-webkit-scrollbar). > Platform coverage: Desktop Why not on mobile? -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Slightly delayed Intent to Ship: getComputedStyle changes on some edge cases.
Hi Emilio, > On Jun 25, 2018, at 11:54 AM, Emilio Cobos Álvarez wrote: > > Hi, > > Just something I figure was worth sending an email for, due to the potential > (ideally positive) web-compat impact. > > In bug 1467722[1], I brought us closer to the spec and to WebKit / Blink in > terms of what happens when we can't return a style for an element from > getComputedStyle (mostly relevant for hidden iframes, for example). It’s very cool to see this getting fixed — thanks for working on this! -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Unshippables
Hi all, I created the following page to track bugfixes, features, or APIs we can't ship (or unship) because it breaks the web. Feel free to contribute, there’s bound to be many more. <https://wiki.mozilla.org/Compatibility/Unshippables> Thanks, -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Array.prototype.values
On Feb 2, 2018, at 7:45 AM, Tom Schuster <t...@schuster.me> wrote: > Any additional ideas how to mitigate the risk here? Chrome seems to > want to add a kill pref for this, from my experience more difficult > for us with the way we define methods in SpiderMonkey. Should that be > a requirement for shipping? Add a pref enabling it for EARLY_BETA_OR_EARLIER, and false otherwise, and let’s see what Nightly/Beta shakes out for a few releases. Then we have time to attempt outreach or other such hacks before burning our release users. -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Unship: Application Cache over Insecure Contexts
Hi Jonathan, > On Jan 18, 2018, at 5:13 PM, Jonathan Kingston <j...@mozilla.com> wrote: > > The intent in Firefox 60 is to ship a pref > “browser.cache.offline.insecure.enable" > to remove AppCache over insecure contexts. > > When the pref is set to false the API will be removed: > > - > > window.applicationCache will be removed > - > > The cache service Firefox implements for AppCache will be disabled over > Insecure Contexts > > > When the pref is set to true the code will produce an additional developer > console warning about the removal timeline. > > In Nightly and Early beta for 60; the pref will be set to false removing > the API. It will be interesting to see if we get reports of pages (that don’t feature test) throwing with the missing applicationCache global. A few years (and laptops) ago I had done some site corpus grepping — I’ll see if I can find any of that data. Later, -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to unship: navigator.registerContentHandler()
Hi Jonathan, > On Jan 3, 2018, at 9:15 AM, Jonathan Kingston <j...@mozilla.com> wrote: > There is a small risk of breakage that we could decide to delay and instead > implement telemetry. However if the site is feature testing rather than > user agent testing there shouldn't be an issue here. As this API throws > errors there is likelihood websites account for it throwing anyway. I would > prefer however to let the removal ride the trains due to it's low risk > before 61 so our ESR doesn't have it. I’m never confident sites are doing feature detection or handling errors… I like the approach of disabling a feature (behind a pref) in non-Release (Beta and Nightly) for a few releases, to see what surfaces in bug reports. > - Is only implemented by Firefox (It was also in Opera Presto 11.60+, RIP) -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to unship: @-moz-document from content pages.
> On Nov 29, 2017, at 10:53 AM, Emilio Cobos Álvarez <emi...@crisal.io> wrote: > > In bug 1035091 I intend to remove support for the @-moz-document CSS > rule in content pages (more exactly in author stylesheets). This is a pretty widely used mechanism to target styles for Gecko. Would it be possible to disable in non-release for a few releases to sniff out any major layout/compat bustage? -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to unship: as in image maps
> On Nov 8, 2017, at 3:49 PM, Emilio Cobos Álvarez <emi...@crisal.io> wrote: > In bug 1317937 I intend to unship the feature of elements acting the > same way as elements in image maps. > > This functionality was specced in HTML 4, but no other browser > implemented it and was removed from HTML 5. > Given that didn't advance for 8 months, that it blocks (or at least > simplifies a lot) longstanding bug 135040, which always bites again and > is a nice source of FIXME comments[1], and the fact that this is not > implemented anywhere else and is not in any spec anymore, we think it's > reasonable to just remove it, and we don't expect any webcompat fallout > from it. We’ll keep an eye out for related bustage reported on webcompat.com. -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to unship: Visibility of window.content to untrusted code
On 9/12/17 5:04 PM, Boris Zbarsky wrote: > We could also delay the removal to after 57 to mitigate 57 risk Or remove it for non-RELEASE_OR_BETA builds for a release or two to see what shakes out in Nightly/DevEdition reports. -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Extensions and Gecko specific APIs
On 7/26/17 3:06 PM, Ehsan Akhgari wrote: > On 07/26/2017 04:58 AM, David Teller wrote: >> Well, at least there is the matter of feature detection, for people who >> want to write code that will work in more than just Firefox. >> moz-prefixing makes it clear that the feature can be absent on some >> browsers. > Until the day that said other browser gets forced into implementing > those prefixed names due to reasons such as mass adoption of the > prefixed names by developers. Here is a practical example from recent > history: > https://searchfox.org/mozilla-central/rev/8a61c71153a79cda2e1ae7d477564347c607cc5f/dom/webidl/HTMLInputElement.webidl#224 Yes, let's avoid repeating vendor-prefix history. It didn't end well last time. -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to unship: moz*Frames attributes of HTMLVideoElement
On 7/7/17 2:41 AM, Anne van Kesteren wrote: > On Fri, Jul 7, 2017 at 8:51 AM, Jet Villegas <jville...@mozilla.com> wrote: >> Depending on what you find, we may have to keep this API around :-/ > > Yeah, I would expect us to follow the "normal" deprecation and remove > path to be more confident in the eventual unshipping: > > 1. Gather telemetry on how often these APIs are used to measure feasibility. > 2. Indicate in the console when these APIs are used that they are deprecated. > 3. Bonus points for indicating in the console by which Firefox release > they are expected to be gone. (This might require more knowledge on > usage though.) > > (Perhaps this is not documented anywhere currently?) It would be good to document this, if it isn't currently. Removing Moz vendor-prefixed stuff is cool in theory, but in reality we risk breaking the web for our user base. -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to unship: window.showModalDialog
On 6/7/17 5:23 PM, Blake Kaplan wrote: > 3 years ago (!) sicking commented in bug 981796 [1] that we were removing > window.showModalDialog. The following year, I wrote a patch to disable it via > a pref at the same time as pushing some telemetry to try to track usage. We > saw more usage than we were hoping, so we held off on turning it off then. > That being said, we didn't implement window.showModalDialog in e10s, so it's > been disabled for those users since (about) Firefox 48. +1. AFAIK, the only (known) fallout from e10s not having this is image attachments failing for older versions of Outlook Web Access -- which brought us inline with other browsers. (It will be interesting to see if non-e10s users file bugs once its gone.) -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to unship: -moz-placeholder pseudo-element and pseudo-class
On 5/25/17 5:48 AM, Ku(顧思捷)CJ wrote: > Mike, do we get any complaint about not supporting webkit placeholder > alias? Nah, not that I'm aware of. I was just looking through GitHub search results and finding some stuff that only includes webkit-input-placeholder: <https://github.com/Noah-Zhang/react-native-wechat/blob/434956d9c49e205198a906bf94d7d506555a1c89/Server/public/stylesheets/style.css> Pretty much everywhere else that has a -moz-placeholder includes a -webkit-input-placeholder (or unprefixed, or both). But I'm guessing add-on code would be the exception. -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to unship: -moz-placeholder pseudo-element and pseudo-class
Hi CJ, On 5/23/17 10:13 PM, Ku(顧思捷)CJ wrote: > I intend to remove "-moz-placeholder" pseudo-element and pseudo-class in > bug 1300896. > > We already supported canonical version of them: > 1. "::placeholder" in bug 1069012, FF 51. > 2. ":placeholder-shown" in bug 1069015, FF 51. > > To support these mozilla-specific aliases introduces special-case handling > in both stylo and gecko, which bring in unnecessary complexity. It's pretty easy to find code on GitHub where only moz/webkit/ms prefixes are used[1]. How complex is the special-case handling, beyond a simple prefixed <-> unprefixed alias? [1] <https://github.com/tochman/website/blob/520b212a96d221d035c9bf3efa9b5b766b035e43/app/assets/stylesheets/theme.css#L136-L141> -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to change editor newline behavior
On 4/4/17 7:12 PM, Ehsan Akhgari wrote: We should also notify the Web Compatibility team. CCing Mike Taylor as proxy. :-) Thanks -- I've let the team know to be on the lookout for new editor-ish bugs. -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.
On 3/22/17 3:27 PM, Boris Zbarsky wrote: On 3/22/17 2:38 PM, Mats Palmgren wrote: Does that sound reasonable? Yes, thank you! Seconded. -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.
On 2/16/17 8:22 PM, Boris Zbarsky wrote: I'm 99% sure there are pages (including some produced by Google and Facebook, last I checked) that do server-side sniffing and send only -moz-appearance to Firefox and only -webkit-appearance to Chrome and "appearance" to no one at all. Yeah, this happens, most predominately on the larger sites that serve N versions to N devices. One example: https://bugzilla.mozilla.org/show_bug.cgi?id=418833#c123 -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: CSS {background,mask}-repeat-{x/y} properties
Hi Tommy, On 11/27/16 9:59 PM, Tommy Kuo wrote: Currently, for web compatibility, I think we should implement these properties. Do we know about any sites that are broken due to background-repeat-x/y? (apologies in advance if you link to a bug that has me commenting on it...) -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removing navigator.buildID?
On 10/31/16 9:16 AM, Henri Sivonen wrote: On Oct 31, 2016 16:02, "Mike Taylor" <mi...@mozilla.com <mailto:mi...@mozilla.com>> wrote: On 10/29/16 9:21 AM, Kohei Yoshino wrote: I think now is a good time to think about navigator.buildID again Thoughts? Seems like we'd potentially end up breaking legacy sites that sniff that to mean "isMozilla". I suggest returning a constant value to general Web sites to avoid this problem. I think that's a good path forward. -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removing navigator.buildID?
On 10/29/16 9:21 AM, Kohei Yoshino wrote: I think now is a good time to think about navigator.buildID again Thoughts? Seems like we'd potentially end up breaking legacy sites that sniff that to mean "isMozilla". -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: some setTimeout()/setInterval() changes
On 10/27/16 12:48 PM, Ben Kelly wrote: On Thu, Oct 27, 2016 at 1:26 PM, Mike Taylor <mi...@mozilla.com <mailto:mi...@mozilla.com>> wrote: On 10/27/16 10:08 AM, Ben Kelly wrote: The short story is that there should be very minimal observable difference. How do these changes compare with other browsers behavior (for the web-observable effects)? Do you have any idea? I honestly don't know how other browsers handle these edge cases. I believe, however, our previous behavior of "freezing time" during a sync xhr was unspec'd and probably unexpected. I don't see anything in xhr.spec.whatwg.org <http://xhr.spec.whatwg.org> about shifting timers around. The html spec references the "pause" concept for alert() modals: https://html.spec.whatwg.org/#pause Again, this says nothing specific about running pending code synchronously when you leave the modal state. It even encourages experimentation around mitigating the impact of the modal on user experience. Not sure if that helps or not. I tend to believe these changes won't have a large compat impact since timers are already rather imprecise and can be delayed for a number of reasons. Cool, thanks -- something to keep an eye on for particularly weird bugs. :) -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: some setTimeout()/setInterval() changes
Hey Ben, On 10/27/16 10:08 AM, Ben Kelly wrote: The short story is that there should be very minimal observable difference. How do these changes compare with other browsers behavior (for the web-observable effects)? Do you have any idea? -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: css multi-column properties (unprefixed)
On 10/7/16 5:07 PM, neerjapanch...@gmail.com wrote: Note that we do not yet support the "column-span" property -- that's covered here: https://bugzilla.mozilla.org/show_bug.cgi?id=616436 So what's the plan for column-span, exactly? We just got a report[1] that the CSSWG site[2] is busted (lol?) because now we understand unprefixed multicol CSS but don't support column-span: all. I'm slightly concerned that other sites serving unprefixed multicol CSS will assume column-span support (though admittedly I don't know the history of multicol support, nor how common they co-occur). [1] https://github.com/webcompat/web-bugs/issues/3429 [2] https://www.w3.org/Style/CSS/current-work -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship imageSmoothingEnabled and remove mozImageSmoothingEnabled.
Hey Thomas, On 8/22/16 4:06 PM, Thomas Wisniewski wrote: Summary: ctx.imageSmoothingEnabled is a Canvas2D context property controlling the interpolation of images drawn to 2D canvases (especially useful for pixel art). Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=768072 Link to standard: https://html.spec.whatwg.org/multipage/scripting.html#image-smoothing Platform coverage: all. Estimated or target release: Firefox 52 Preference behind which this will be implemented: None. This has been unprefixed in Chrome since version 41, and it should ship unprefixed in Safari 10. It looks like webkitImageSmoothingEnabled is very, very low (0.008%): <https://www.chromestatus.com/metrics/feature/timeline/popularity/267> Are you aware of any plans for it to be removed from Blink as well? (unprefixed usage is also super low (0.027%), but seems to be growing: <https://www.chromestatus.com/metrics/feature/timeline/popularity/268>) -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [Go Faster] WebCompat Go Faster Add-on
On 6/27/16 3:20 PM, Justin Dolske wrote: I'm asking because this is code shipping to end-users, so I'd expect it to adhere to basically the same engineering standards as code that ships as part of baseline Firefox. AFAIK this is the first time that's really been a question -- our other system addons (Hello, Pocket) started off in Firefox, and just changed their delivery vehicle. To be more specific: * Who are the people that will be reviewing code that ships in this addon? I don't see anything in the docs about code review or who can do it. Will there be a module? Would the relevant platform reviewers be used when shimming in DOM APIs? I don't know how the module system works wrt go faster add-ons. But maybe someone can add some clarity around this this. I'd likely be reviewing patches written against sites, within our team. And we'd be asking people with more Firefox/XPCOM/go faster experience to review the site patching infrastructure. We'd absolutely be asking for review from DOM peers if and when we shim any APIs. If someone wants to step up and volunteer to review all our patches, that's also great. * The docs do expand a bit on testing, but it sounds like a one-time QA signoff. That's an important part, but I don't see anything about automated / ongoing tests (against product code or website code). For example, if a Gecko change breaks something the addon is relying on, when will that be noticed? Or if the addon's patch for a site stops working (or, worse, breaks it!) due to a change the site deploys after the addon is released, when will that be noticed? I sort of expanded on that in my reply to Benjamin. Right now it's a very hand-wavey TODO item here: <https://wiki.mozilla.org/Compatibility/Go_Faster_Addon#TODO> We don't plan on shipping site patches without this kind of ongoing sites -- sites change all the time, and often developers fix bugs without letting us know (once we're at the outreach stage). * Similarly to correctness testing, how is performance testing dealt with? For this go faster add-on, or go faster add-ons in general? -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [Go Faster] WebCompat Go Faster Add-on
On Mon, Jun 27, 2016 at 2:26 PM, Cory Price <cpr...@mozilla.com <mailto:cpr...@mozilla.com>> wrote: On Mon, Jun 27, 2016 at 11:05 AM, Justin Dolske <dol...@mozilla.com <mailto:dol...@mozilla.com>> wrote: What's the policy for reviews and testing with this addon? You can see the current process for deploying things in the Go Faster documentation (Wiki <https://wiki.mozilla.org/Firefox/Go_Faster>, Release Process <https://docs.google.com/document/d/1x27I7hAmWDWiqk3o3YC3fklhE3N59bdgHCQHF5p_lkU/edit#>). Thanks, I wasn't aware of the Release Process doc (so I guess I owe an "Intent to Implement" email to the right lists in the coming weeks). On 6/27/16 1:45 PM, Benjamin Smedberg wrote: > This seems like an inadequate answer to the particular question: who in particular is the module owner of this code, who is responsible for doing code review? How do other go faster addons operate? My naive answer is people on our team. > And who is the QA/QE lead for this addon and what > kind of systems will be used to determine whether a particular webcompat > tweak is working both before before and after deployment? If you read the explainer doc, near the end we mention needing automated testing to verify that patches are needed post-deployment. We've built similar things in the past for testing "bugfix" regressions. The design of that is TBD, but our team will build it and monitor it. One of the requirements of this addon is that it can be (temporarily) disabled so site owners can verify that they've fixed things. We don't have dedicated QA resources, so this will likely be a manual process by our team: turn it off, verify, turn it on, verify, etc. -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: getUserMedia(cam+mic) to become all-or-nothing
On 5/12/16 2:48 PM, Jan-Ivar Bruaroey wrote: Our original intent behind those choices was to let users join a video conference as an "audio only" participant. Unfortunately, sites don't expect this behavior and often don't work right when the track is missing. Fixing sites sounds good. Are there any risks of breaking sites with this change? I would assume if we're aligning with Chrome (if they follow the spec here), probably not. But I don't actually know. -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Use Counter: Everything
On 5/11/16 3:56 AM, Cameron McCormack wrote: Recording use counter information as we parse CSS is not too expensive, although if we were doing it for all ~300 properties I’d be wanting to check that we don’t slow sheet parsing speed down appreciably. It’s probably fine, but see the work that is done when recording one here: https://dxr.mozilla.org/mozilla-central/source/dom/base/nsDocument.cpp#13129 We use a std::bitset<> on the document to store the “use counted or not” for each use counter so the memory overhead is low. Someone with more familiarity about the actual Telemetry payload can say whether it would be alarming to have ~300 new entries, if you plan to eventually include all properties. bsmedberg got pinged in the bug to give feedback on that. But starting with recording all of our non-standard property usage sounds fine. I've changed the bug title to start with non-standard props and we can take it from there. Note that UseCounters.conf only supports longhand properties currently, since we record them in here, where we’ve already expanded shorthands out to their component longhands: https://dxr.mozilla.org/mozilla-central/source/layout/style/nsCSSDataBlock.cpp#712 We could handle shorthands by recording them earlier, up in nsCSSParser somewhere. Good to know, thanks. -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Use Counter: Everything
On 5/10/16 6:53 PM, Jonas Sicking wrote: The moz-isms aren't as easy to spot in the DOM since there's much less of a history of prefixing DOM-API names, but they certainly exist. Is there any handy way of identifying these, other than cross-referencing with the relevant specs? -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Use Counter: Everything
On 5/10/16 3:05 PM, Jack Moffitt wrote: We have the Chrome popularity data, and we have the Edge team's data which covers the CSS spectrum quite well. I think it would be far more useful to start covering the DOM API spectrum. For example, it's pretty clear from existing data sources which CSS properties Servo should focus on. But we have very little data for which DOM APIs are important. Interesting, my own interests are naturally skewed towards finding the moz-isms and understanding how and when we can get rid of them (if ever). But I can see how understanding DOM API usage is more relevant when building a new browser engine. What value does having even more CSS property data provide above and beyond the value that can be extracted from the existing sources? Is that value greater than the value we could extract by focusing on data that doesn't currently exist? I assume the answer to the first question is that it gives us data that doesn't exist about -moz prefixed properties. Regarding the second question, my opinion is that we can get a lot more benefit from covering other areas than CSS. I'm curious to hear more informed opinions on this than my own. ¿Porqué no los dos? Right now no source of data will tell us if it's safe to remove :-moz-dir() once we ship :dir(), for example. https://bugzilla.mozilla.org/show_bug.cgi?id=1270406 And as Steve already replied, making decisions based on CSS (or JS) served to browsers with different UA strings can be problematic. If you're Safari Mobile, you'll end up with a lot more WebKit-isms than if you're Fennec. But yes, I absolutely agree we should Use Counter DOM APIs as well. As to where this should live, it seems unfortunate that we would end up with three repositories of data: Chrome's use counters, Edge's platform status, and now a Mozilla one. Is it not possible to consolidate this collection effort? I don't have any strong opinions on where the data lives. -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Use Counter: Everything
On 5/10/16 2:11 PM, Mike Taylor wrote: Having recently discovered UseCounters.conf[1], I'd like to add use counters for all CSS properties, starting with prefixed props. And likewise for Moz-prefixed DOM props and methods. Link to bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1271752 -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to Use Counter: Everything
Having recently discovered UseCounters.conf[1], I'd like to add use counters for all CSS properties, starting with prefixed props. And likewise for Moz-prefixed DOM props and methods. Ultimately, I'd like us to have a Firefox equivalent to https://www.chromestatus.com/metrics/css/popularity to help us make decisions around removing support for non-standard-isms without breaking the web. (https://platform-status.mozilla.org/ seems like a good home for this kind of data) Before I start writing patches, is there any reason to not do this? [1] https://dxr.mozilla.org/mozilla-central/source/dom/base/UseCounters.conf -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: ParentNode.prepend(), ParentNode.append(), ChildNode.before(), ChildNode.after(), ChildNode.replaceWith()
On 4/19/16 9:13 AM, Boris Zbarsky wrote: On 4/19/16 3:53 AM, Florin Mezei wrote: Sounds like this may cause WebCompatibility issues? How worried are we about this? Mildly but not desperately. Given that 48 moves to Dev Edition in ~1 week, is there any reason to not wait for the 49 cycle to let it bake a full Nightly cycle (and potentially let us find compat bustage)? Can we mitigate this through testing? Hard to say. We could try to mitigate through searching web content for the relevant method names, but I believe that was already done when writing the spec. I could be wrong, of course Past that, I'm not sure how to design a test plan that would catch issues, if any, here. :( Stuff like this is easy to test for once we know what breaks. It's really hard to predict what weird usage in the wild might break this though... -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [Bug 1224726] High memory consumption when opening and searching a large Javascript file in debugger.
On 4/11/16 5:04 PM, Mats Palmgren wrote: He touched 283 bugs in the last 48 hours, most of which are FIXED. If anyone in the QA org reads this list, maybe they could reach out and teach him how to more effectively contribute? (I see "[bugday-20160323]" from <https://quality.mozilla.org/event/bug-verification-day-109/>.) -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: -webkit-background-clip:text
On 3/22/16 3:11 PM, Daniel Holbert wrote: - Therefore, I'm not sure we get any real-world benefit from guarding this feature with an additional dedicated pref. And there'd be a complexity cost from making sure we test all combinations of pref enabled/disabled states, & do the right thing when one or the other pref is disabled. +1. It has been nice to have a single pref to flip to test for potential regressions (and for instructing people to do the same thing). -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: -webkit-background-clip:text
Just wanted to say thanks for working on this -- it was a pleasant surprise to come back from PTO and see this nearly done! On 3/21/16 11:59 PM, Ku(顧思捷)CJ wrote: Summary: -webkit-background-clip:text has been available for years in webkit based browsers and has seen widespread usage on the web. This css property is currently available in Chrome, Safari and Edge. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=759568 Link to standard: https://compat.spec.whatwg.org/#the-webkit-background-clip-property Platform coverage: All platforms. Estimated or target release: Firefox 48 Preference behind which this will be implemented: layout.css.prefixes.webkit Note: The way we support this property value is a little bit different with webkit. After turning on layout.css.prefixes.webkit, 1. -webkit-background-clip property is supported. 2. In gecko, "text" is a valid value for *both* background-clip and -webkit-backkground-clip. 3. In webkit, "text" is a valid value for only -webkit-backkground-clip. If you set "text" into -webkit-background-clip and serialize background-clip prop by style.getPropertyValue, you will still get "text", which is problematic. dholbert gave more detail explanation on bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=759568#c40 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Update on WebKit prefix support in Gecko.
Howdy dev-platform (cross-posting fx-team for maximum synergy),
A quick update on our progress of implementing the WebKit related deps
of Bug 1170774.
In Bug 1213126 we set layout.css.prefixes.webkit to true by default to
let it ride the trains and see if anything exploded. Not surprisingly,
some stuff blew up.
So since Bug 1238827, we're restricting layout.css.prefixes.webkit=true
to non-Release builds.
(If you want to learn what layout.css.prefixes.webkit enables, check out
Bug 1170789 and its CSS deps. One other DOM interface is behind the pref,
Bug 717722: implement WebKitCSSMatrix
This fixes a ton of mobile sites. The Compat Spec stuff was moved into
the Geometry spec making WebKitCSSMatrix an alias of DOMMatrix (after
changing a few things to make it compatible). Apple and Google have bugs
on file to do this, which is cool.)
The following are things that we discovered we needed to be compatible
with the web once you support some WebKit prefixed stuff since turning
on layout.css.prefixes.webkit.
- Bug 1239799: Add support for "@media (-webkit-transform-3d)" as a
media query for 3d transform support.
Turns out some sites using older versions of Modernizr will only do 3d
transforms if you support this. So now we do, and we've specced it:
https://compat.spec.whatwg.org/#css-media-queries-webkit-transform-3d
- Bug 1236979: send 'webkitTransitionEnd', 'webkitAnimationEnd', etc.
events instead of their standard equivalents, if listeners only exist
for prefixed event name.
Lots of (mapping) sites break if you don't do this. And probably more
things we don't know about. Edge, Safari, and Blink all do this, so now
we do too. (Yes, it's gross and weird.) A PR is in progress to get this
specced in DOM.
- Bug 1241021: Support camel-cased and webkit-cased CSSStyleDeclaration
attributes for getting & setting WebKit prefixed styles
Some sites do things like $(foo).css('-webkit-bar', 'baz'). We found a
lot of image sliders break if you don't support this. In order for that
to work, you have to support setting/getting
elm.style['WebkitTransition'] in addition to elm.style['webkitTransition'].
But wait, there's more.
- Bug 1246796: Add support for elm.style['-webkit-foo'] style CSSOM
getters/setters.
Yeah. Apparently every single browser except us supports this (for their
own prefixes too). Fun.
- Bug 1248444: Allow writing to cross origin style sheets
All non-Gecko browsers will let you write to a 3rd party stylesheet via
insertRule (even though CSSOM says this is a SecurityError). We need to
do some careful research here to make sure we can safely do the same.
- Bug 759568: Implement -webkit-background-clip: text;
- Bug 124: Implement -webkit-text-fill-color
- Bug 1248708: Implement -webkit-text-stroke
These three are all related to fancy typography effects that sites use
with -webkit- prefixed gradients. If you support gradients but not
these, you're gonna have a bad time™: https://cloudup.com/cVP9AppLMAv
dholbert has a good proposal to ignore webkit-prefixed gradients if you
find -webkit-background-clip: text in the same rule. That should allow
us to ship enable our webkit support without being blocked on these
three bugs (and without regressing Release's behavior for this
typography gradient clipping). See Bug 1248785 for that.
The following things have been disabled:
- Bug 1249134: disable -webkit-appearance alias for now.
The behavior between -moz-appearance and -webkit-appearance is too
different to be useful. We have
https://github.com/whatwg/compat/issues/6 filed to spec the way
-webkit-appearance is used (and how designers rely on it for fancy
forms), and once we're there we'll be following up with bugs against Gecko.
- Bug 1237720: put "-webkit-min-device-pixel-ratio" behind it's own pref
and disable it.
Supporting this fixed a number of mobile sites, but unfortunately broke
Google Docs on HiDPI devices. :( So it's disabled for now. Maybe it will
come back one day.
Things we've already shipped, or are riding the trains:
- Bug 920734: window.orientation / orientationchange event support (44)
- Bug 264412: element.innerText (45)
- Bug 823483: Percentage max-width does not seem to affect contributions
to intrinsic min-width (46)
Lots and lots of sites are fixed as a result. \o/
If you only use Release or Beta, consider using Nightly Fennec to see a
lot of improvements. And please keep reporting strange bustage you see
in Dev Edition or Nightly Desktop that is fixed by toggling
layout.css.prefixes.webkit to false and needinfo? :miketaylr.
Big thanks to bz, dbaron, dholbert, foolip, hallvors, heycam, karlcow,
wchen, roc, zcorpan, and many others for patches, reviews, spec comments.
(OK, this wasn't such a quick update)
later,
--
Mike Taylor
Web Compat, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.
Re: Intent to implement and ship: WebKitCSSMatrix
On 1/14/16 9:09 PM, L. David Baron wrote: It seems to me this is important to have behind a preference that is specific to new webkit-prefixed features, given the compatibility risks of shipping support for some but not all webkit-prefixed features. (It's possible it could be the same preference as other new webkit-prefixed CSS features.) /lists.mozilla.org/listinfo/dev-platform This is probably a good idea, given the (frequent) interdependency between WebKitCSSMatrix and webkitTransform: <https://github.com/whatwg/compat/blob/master/compatibility.bs#L762-L768> -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Implement/Ship: document.elementsFromPoint
On 1/14/16 9:46 PM, Kyle Machulis wrote: *Summary*: We don't currently support documents.elementsFromPoint, while IE and Chrome do (I'm not sure if Opera and Safari have gotten around to it yet). Opera does have document.elementsFromPoint and Safari does not (yet). I couldn't find an open bug for WebKit, so I filed one: <https://bugs.webkit.org/show_bug.cgi?id=153137> Edge and IE 10 ship a prefixed document.msElementsFromPoint. -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: FIDO U2F API
On 12/2/15 8:53 AM, Ms2ger wrote: I don't remember what the current conventional wisdom about prefixing is, but I would be open to shipping with a prefix if people thought that would ease pain in the eventual transition. No. Nonononononononono. This is the conventional wisdom. Prefixes end up causing pain. -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: window.orientation and orientationchange event
On 10/20/15 6:12 AM, Jonas Sicking wrote: On Tue, Oct 20, 2015 at 2:49 AM, Mounir Lamouri <mou...@lamouri.fr> wrote: Should we add this to the Screen Orientation specification? I think so yes. I also think so. In my mind the Compat Standard should be transitional in nature, rather than something we maintain forever. Ideally the "standard" equivalents (or logical parent specs or whatever) will take in what's specced there as historical APIs or aliases needed for compatibility with the de-facto web. -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to converge with Chromium / Blink for not firing events on ’s from dropdowns
Hi Mike, On 10/15/15 4:00 PM, Mike Conley wrote: That’s when I found out that event behaviour for ’s is not spec’d out, and the way in which events are fired differs widely from browser to browser. I tested Firefox Nightly (non-e10s), Safari, Chrome, Internet Explorer and Edge, and posted my findings at [2]. What I’m proposing is that we try to converge with Chrome / Blink’s behaviour on these events, where we do not fire any events on ’s, ever, whenever e10s is enabled by default. <https://bugzilla.mozilla.org/show_bug.cgi?id=715990> seems relevant -- we don't fire click events on s in Fennec either (because I forgot to land the very first patch I wrote, lol?). AFAIK, there has been no compat fallout from not supporting this. -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: dialog=1 for window.open from content
On 10/2/15 2:53 AM, Ehsan Akhgari wrote: Before I go whole-hog trying to fix bug 1095236, I'm curious to know if we really want to continue supporting dialog=1 from content, or if it's safe to just ignore that feature like the other browser engines (which I think would be the fastest path towards fixing bug 1095236). Are there any really good arguments to keep supporting it? A good argument, no. But these things can end up having a web compat impact. I personally think that the risk of web compat is not that high here but if we want to be sure, we can add a use counter for the feature and measure how much it's used in the release population, and decide based on that. I agree with Eshan here. Usually it's banks scattered around the world that depend on these obscure features. And banks are some of the trickiest sites to diagnose (people don't trust me with their online bank login details, weirdest thing) and *then* you have to convince the bank to update their sites. But yeah, the guesswork goes away with a use counter. -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rewriting YouTube's Flash video embedding code to use HTML video?
On 8/21/15 6:31 PM, Hubert Figuière wrote: On 21/08/15 06:17 PM, Chris Peterson wrote: Bug 769117 discusses whether Gecko should detect YouTube's old embedding boilerplate and automatically rewrite it to use the current code. Firefox and Safari extensions [1] [2] already do this, but should Gecko include this feature directly? It would improve users' video experience and fix dead links if/when Firefox or YouTube stop supporting Flash. OTOH, this is a site-specific workaround and thus might not belong in Gecko itself. It think that it is a feature that could be implemented in Firefox: 1. make it so that the rules are rewritable without updating the browser, or at least touching the core. ESR comes to mind as a reason why we'd love to update these. This sounds like a good use case for a system addon described by the Go Faster initiative. [1] 2. make it cross platform. Mobile (including FirefoxOS) would completely benefit from that. Case in point, Safari on iOS has been doing that for a very long time. +1. [1] https://wiki.mozilla.org/Firefox/Go_Faster#Project_1:_Ship_features_as_system_add-ons -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to unship: Prefixed mozRequestAnimationFrame and related APIs (mozAnimationStartTime, mozCancelAnimationFrame)
On 7/16/15 19:08, Boris Zbarsky wrote: Web compat impact for mozRequestAnimationFrame/mozCancelAnimationFrame: Not known for sure, but expected to be small to none. Pretty much any real-life web code that uses this API will also used the unprefixed version or at worst fall back to setTimeout/setInterval. Unfortunately, a use counter would not help much here because of web sites that prefer using the prefixed version to the unprefixed one. Will we ever run into the same problems with unprefixing rAF raised on blink-dev[1]? I see 932322 was partially backed out and 943958 seems to describe the `var requestAnimationFrame = window.requestAnimationFrame` problem. [1] https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/5S7qeLSXT5Q/aN01cHXbVg8J -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
Hey David, On 5/6/15 13:09, dgra...@github.com wrote: Although IE 11 supports this API as well, we have not enabled it yet. The browser displays a popup dialog asking the user for permission to copy to the clipboard. Hopefully this popup is removed in Edge so we can start using JS there too. I just haven't had a chance to test with it yet. Thanks for mentioning this--I suspect other sites would also fall back to Flash if our UX is similarly annoying. Right now, there isn't a reliable way to feature detect for this API in JS. We use user agent detection instead, just for this feature. Any suggestions here would be much appreciated. You can use the document.queryCommandSupported()[1] or document.queryCommandEnabled()[2] APIs to check for support. [1] https://developer.mozilla.org/en-US/docs/Web/API/Document/queryCommandSupported [2] https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIDOMNSHTMLDocument#queryCommandEnabled%28%29 -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: document.execCommand(cut/copy)
Hi Tantek, On 5/6/15 10:59, Tantek Çelik wrote: Since we have no legacy to deal with, we can start conservative, and wait for web developer feedback, and iterate accordingly. We're behind IE10 and Chrome 43 in implementing this feature [1], so at some level there will be existing content we need to deal with. Interoperability with how they behave would be a win. Ideally, whatever we do to protect our users can make it back to Hallvord to spec and other implementers to match, otherwise Flash-for-clipboard-access won't be going anywhere. [1] http://updates.html5rocks.com/2015/04/cut-and-copy-commands -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: MouseEvent.offsetX/Y
On 3/1/15 17:58, smaug wrote: Haven't changes from integer to doubles caused issues in some cases. Boris might recall some examples. IE just reverted from using doubles on MouseEvent for compat reasons: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28029#c6 -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: Array.prototype.contains is going away again
On 10/1/14, 11:52, Till Schneidereit wrote: Unfortunately, it turns out that Array.prototype.contains breaks the web. Or, the MooTools-using parts of the web, at least. It looks like apps using Ember.js are affected as well: https://github.com/emberjs/ember.js/issues/5670 -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
