Closed
Bug 1177263
Opened 9 years ago
Closed 9 years ago
Enable CSS Unprefixing Service for all sites (e.g.., remove domain whitelist restriction)
Categories
(Core :: CSS Parsing and Computation, defect)
Core
CSS Parsing and Computation
Tracking
()
RESOLVED
DUPLICATE
of bug 1213126
Tracking | Status | |
---|---|---|
p11 | + | --- |
People
(Reporter: miketaylr, Unassigned)
References
Details
(Whiteboard: [compat])
For improved compatibility across the entire web (rather than just a few sites that we whitelist), we need to enable the CSS unprefixing service for *all* sites.
It's likely this has performance implications--so we should try to figure that out at some point as well.
(We also probably need a way to signal this to developers, so as to not be entirely confusing).
Reporter | ||
Updated•9 years ago
|
Comment 1•9 years ago
|
||
Hi Daniel, MikeT had said you were doing some instrumentation to understand the performance impact of globally turning on the CSS Unprefixing Service. If our screenshot analysis goes well, and barring any insane perf hits that this might be a near term possibility.
Are you (or someone you know) actively working on this bug?
Flags: needinfo?(miket)
Flags: needinfo?(dholbert)
Comment 2•9 years ago
|
||
(In reply to :shell escalante from comment #1)
> Hi Daniel, MikeT had said you were doing some instrumentation to understand
> the performance impact of globally turning on the CSS Unprefixing Service.
I did some informal instrumentation (with timestamps & printf) locally just to get a rough idea, on a few sites (gmail, and a few of our whitelisted Chinese sites). Basic results were: there is a measurable perf hit for each roundtrip, though I think it was a small fraction of a millisecond (maybe .02 to .1 ms, I think) per roundtrip. This is pretty negligible & hence was somewhat encouraging; but I'm also testing on a moderately-powerful thinkpad. The hit might be more substantial on a phone.
> If our screenshot analysis goes well, and barring any insane perf hits that
> this might be a near term possibility.
I'm not so much concerned about "insane perf hits" (that's unlikely) but rather a subtle perf hits across *the whole web*, once we enable this globally (particularly on underpowered devices).
Quoting dbaron from bug 1181624 comment 7:
# we will not expose the unprefixing service in its
# current state (or anything close to it) to all sites. Most of the things in
# it can and should be done in better ways in order to expose them everywhere.
One possible way forward is described in bug 1170774 comment 7.
> Are you (or someone you know) actively working on this bug?
Not at the moment, but I plan to soon (with work probably being done in supporting bugs). This is on my plate for this quarter.
Flags: needinfo?(dholbert)
Comment 3•9 years ago
|
||
("roundtrip" = the CSS parser sending some unrecognized prefixed CSS through the CSS Unprefixing Service.)
Comment 4•9 years ago
|
||
Hi Daniel, :) thanks for the detailed response. Being a Project Manager - i'm just going to clarify on timing (we're annoying that way).
when you say this is on your "plate for this quarter" - does that mean to land work sometime before August 10th when Fx43 moves from Nightly to Aurora, which is the last Nightly cycle in Q3.
Flags: needinfo?(miket) → needinfo?(dholbert)
Comment 5•9 years ago
|
||
(In reply to :shell escalante from comment #4)
> when you say this is on your "plate for this quarter" - does that mean to
> land work sometime before August 10th when Fx43 moves from Nightly to
> Aurora, which is the last Nightly cycle in Q3.
That's not exactly what I meant, but I can aim for that!
(For platform team, something being a goal in a particular quarter [as in, July through September] means having something checked in to mozilla-central by the end of that quarter.)
Flags: needinfo?(dholbert)
Comment 6•9 years ago
|
||
Blassey caught my mistake - i meant the date to be SEPT 21 for when Fx43 goes from nightly to aurora.... i put in the 42 date. Fx43 is still Q3. Sorry Daniel. meant to check that it would ride the trains with Fx43.
Flags: needinfo?(dholbert)
Comment 7•9 years ago
|
||
Thanks for the update, shell. That seems quite feasible. (The reduced time-pressure vs. comment 4 is nice. :))
Flags: needinfo?(dholbert)
Comment 8•9 years ago
|
||
Could we enable the CSS Unprefixing service in __Nightly only__ without whitelist at all?
Objectives:
1. Give the possibility for more people to test
2. Having possibly reports of bugs where it fails (CSS not fixed, perf issue, crashes)
3. Having an organic traffic for bug reporting with sites we didn't think about.
Options:
A pref for disabling it, so we can compare before/after.
Reporter | ||
Comment 9•9 years ago
|
||
(In reply to Karl Dubost :karlcow from comment #8)
> Could we enable the CSS Unprefixing service in __Nightly only__ without
> whitelist at all?
Do you mean just Nightly Fennec, or everywhere?
I think the Fennec team is on board with something like this, but I don't know about Desktop. ni?ing margaret and mfinkle to be sure.
> Options:
> A pref for disabling it, so we can compare before/after.
This already exists, right? layout.css.unprefixing-service.enabled
Flags: needinfo?(mark.finkle)
Flags: needinfo?(margaret.leibovic)
Comment 10•9 years ago
|
||
I am OK with landing this for Fennec on Nightly. To be extra careful, we could land with a NIGHTLY_BUILD flag so we are sure it stays on Nightly until we are satisfied with all aspects of the feature.
Flags: needinfo?(mark.finkle)
Comment 11•9 years ago
|
||
(In reply to Mark Finkle (:mfinkle) from comment #10)
> I am OK with landing this for Fennec on Nightly. To be extra careful, we
> could land with a NIGHTLY_BUILD flag so we are sure it stays on Nightly
> until we are satisfied with all aspects of the feature.
+1
Flags: needinfo?(margaret.leibovic)
Reporter | ||
Comment 12•9 years ago
|
||
I spoke with dholbert about this on IRC and we agreed that rather than enabling the CSSUnprefixingService as-is temporarily on Nightly (which we have no plans on shipping in Release), we can add a pref to allow people to opt-in to the as-is prototype behavior. I've filed Bug 1189922 to track that.
Comment 13•9 years ago
|
||
And thanks to Daniel and Mike this is done in Bug 1189922 \o/
Reporter | ||
Comment 14•9 years ago
|
||
Given that we plan on shipping native support for webkit prefixes (rather than use the unprefixing service) let's close this as a dupe of Bug 1213126.
As mentioned is Comment #13, there's a layout.css.unprefixing-service.globally-whitelisted pref we can use for testing until that happens.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•