pdate 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
d 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
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
nswer 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
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.mo
t 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 Comp
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
m 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 C
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
nsole (...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
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 C
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,
--
Mi
BTWyB6GH7j_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
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
verage: 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
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
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 s
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
t / 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
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 Comp
it- prefixes). Just
> as a data point, we didn't have a single reftest that failed without it, only
> parsing tests.
>
> Let me know if you think otherwise though.
LGTM.
--
Mike Taylor
Web Compat, Mozilla
___
dev-platform
ping?
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 Com
ne 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
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
_
e 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
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-platfor
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, Mozi
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-platfo
pected 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 we
s 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-plat
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
On 5/24/17 1:50 PM, Boris Zbarsky wrote:
> On 5/24/17 1:06 PM, Mike Taylor wrote:
>> [1]
>> <https://github.com/tochman/website/blob/520b212a96d221d035c9bf3efa9b5b766b035e43/app/assets/stylesheets/theme.css#L136-L141>
>
> Sadly, that code is already buggy in Firefox: i
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
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
__
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
l.
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.mo
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
On 10/31/16 9:16 AM, Henri Sivonen wrote:
On Oct 31, 2016 16:02, "Mike Taylor" 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
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
On 10/27/16 12:48 PM, Ben Kelly wrote:
On Thu, Oct 27, 2016 at 1:26 PM, Mike Taylor 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 compar
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
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
<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
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
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
_
gt;
Comments welcome, thanks.
--
Mike Taylor
Web Compat, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
es 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-plat
ayout/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.
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?
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
__
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=12
la-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
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 Compa
7;s a PITA to deal with,
assuming Browser B is buggy.
(That said, I wouldn't be surprised if some top site out there falls
over on a second visit w/o a cookie it was expecting.)
--
Mike Taylor
Web Compat, Mozilla
___
dev-platform mailing list
dev-plat
y.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
ght 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 lis
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-platfo
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.mozilla.org/listinfo/dev-platform
WebKit stuff".
e.g., <https://bugzilla.mozilla.org/show_bug.cgi?id=1244464#c8> (but not
the cause of this bug in particular).
--
Mike Taylor
Web Compat, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
ind 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@li
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
s 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
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
_
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.mozill
rust 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-platfor
e. [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
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-pl
veloper.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
s.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
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 C
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
71 matches
Mail list logo
