Closed Bug 1168280 Opened 4 years ago Closed 3 years ago
CSS Unprefixing service and interaction with devtools
This is the summary of the issue. We created a CSS Unprefixing service, fixing some WebKit CSS properties. Taking for example http://girlschannel.net/ which had an issue with WebKit CSS gradient on Firefox for Android. See bug https://webcompat.com/issues/937 Firefox without the unprefixing service. When we click the input element in the DOM inspector, we don't see the gradient because it's a Webkit property. So far so good. See Screenshot unfixed. Firefox with the unprefixing service. When we click the input element in the DOM inspector, the CSS gradient is this time displayed in the right column. If I click on the link, the Style Editor opens at the position of the property and displays the non-fixed CSS. See Screenshot fixed. It's a bit disturbing. I wonder if there would be a way for the Developer Tools to know that the site has been fixed and probably to advertise that there was a fix on that node. Maybe putting the properties in the right column of the inspector with a warning or something.
(In reply to Karl Dubost :karlcow from comment #0) > It's a bit disturbing. To clarify -- is the "disturbing" thing that the style shown in the DevTools "Rules" view doesn't match the specified style? That can already happen, without any CSS Unprefixing Service activity. Try e.g. this data URI: data:text/html,<div style="border: 1px">Inspect me If you right-click & choose "Inspect Element", you'll see that this shows up in DevTools' "Rules" view as having "border: 1px none", even though I didn't manually specify "none". Similarly, this URI... data:text/html,<div style="border: lime">Inspect me ...shows up in DevTools "Rules" view as having "border: medium none rgb(0, 255, 0)". And this URI: data:text/html,<div style="-moz-box-sizing:border-box">Inspect me shows up as having "box-sizing: border-box". (No "-moz".) Essentially, DevTools displays a re-serialized view of the property value, which doesn't always use the same syntax that the author provided. That may be "disturbing", but it's unrelated to the CSS Unprefixing Service. :) > I wonder if there would be a way for the Developer Tools to know that the > site has been fixed and probably to advertise that there was a fix on that > node. This is probably doable, but there may be a cost to tracking this... and I'm not sure how much of a benefit there is, because this would only matter for sites on the whitelist, and those sites are supposed to be (a) extremely limited in number, and (b) unreceptive to suggestions that they test & support non-WebKit-based browsers.
I think bug 984880 will give you what you want, but I'll let the experts comment.
Component: Developer Tools → Developer Tools: Inspector
bug 984880 will help and I'm very much looking forward to that one. It's still a very good point that it would be nice to have some extra flagging of "Firefox-generated" fixup style rules. At the moment it might not be worth our time because only a few "fixlisted" sites are affected - but it would be great to have devtools explain both to ourselves and to webmasters what's actually happening. Could we start having a single flag somewhere that gets set if the unprefixing service is used, and gets queried by devtools to show a small informative message - somewhat like "Warning: Firefox modified the CSS on this site, rewriting non-standard code. See [link] for details."
I confirm that bug 984880 is the main fix here. It will make sure styles appear as authored both in the Inspector tab (the "Rules" sidebar), and in the Style-Editor tab. I also agree that having some sort of information telling users that a certain vendor-prefixed property was replaced by its non prefixed version would help. I suggest that we start simple and log something in the console for this. The devtools web console panel has a "CSS" log category already. Why not log something there for a start? All invalid properties are already logged there, so it makes sense to me that invalid properties that are automatically fixed by firefox would be logged there too.
Bug triage. Filter on CLIMBING SHOES
Priority: -- → P3
The unprefixing service was removed in bug 1259348, so I think this is no longer relevant.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INVALID
Indeed - thank you!
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.