Closed
Bug 974686
Opened 10 years ago
Closed 9 years ago
New domUtils.getRuleEndLine and domUtils.getRuleEndColumn functions would be useful for the DevTools inspector
Categories
(Core :: CSS Parsing and Computation, enhancement)
Core
CSS Parsing and Computation
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: pbro, Unassigned)
References
Details
Today we have domUtils.getRuleLine() and domUtils.getRuleColumn() functions which we use in the devtools to reference specific rules (shown in the inspector) to their locations in the parent stylesheet file. It would be very useful to have the corresponding domUtils.getRuleEndLine() and domUtils.getRuleEndColumn() so that we could easily extract a text range from the stylesheet's cssText. The usecase is the following: Up until now, we've been showing applied css rules only in the inspector, and we're missing other browser vendor prefixed properties for example, or invalid properties. These are not shown at all. We'd like to show the style as it was authored, and visually show the diff between the properties that are applied and those that aren't. Using getRuleLine/Column and getRuleEndLine/Column would make it easier for us to extract the actual authored style from the cssText (it would avoid having to tokenize after the start position to find the closing } symbol). Of course, this is assuming it's actually an information that is already available somewhere and just not exposed via inDOMUtils.cpp yet.
Comment 1•10 years ago
|
||
We don't track that sort of thing internally, just like we didn't track the line/column until we needed to expose them. So we'd need to add some members to every CSS rule. :(
Updated•10 years ago
|
Component: DOM → CSS Parsing and Computation
Updated•10 years ago
|
Severity: normal → enhancement
Reporter | ||
Comment 2•10 years ago
|
||
It turns out that for inline and/or minified styles (I'm not sure which causes it), the DOMUtils.getRuleLine function returns incorrect information. Here is what I tried: - Open google.com - Open the scratchpad editor from the tools/webdevelopers menu - Switch the scratchpad to "browser" environment - Enter the following: XPCOMUtils.defineLazyGetter(this, "DOMUtils", function () { return Cc["@mozilla.org/inspector/dom-utils;1"].getService(Ci.inIDOMUtils); }); let doc = gBrowser.tabs[0].linkedBrowser.contentWindow.document; let rules = doc.querySelectorAll("style")[1].sheet.cssRules; DOMUtils.getRuleLine(rules[1]) --> This returns 11, which is incorrect. And in fact it returns 11 for all rules in this stylesheet. --> If you use the devtools inspector and search for the second <style> element in <head> you'll see that it contains a long string of minified css code. Therefore, the returned value should be 0. I haven't checked for all rules, but getRuleColumn seems to return the right value though.
Summary: New domUtils.getRuleEndLine and domUtils.getRuleEndColumn functions would be useful for the DevTools inspector → DOMUtils css rules location issues: getRuleLine incorrect for inline styles and missin end line/column
Reporter | ||
Comment 3•10 years ago
|
||
On top of this, as explained in comment 0, it would be very useful to get the rule's end location too. This is blocking bug 984880.
Reporter | ||
Updated•10 years ago
|
Summary: DOMUtils css rules location issues: getRuleLine incorrect for inline styles and missin end line/column → DOMUtils css rules location issues: getRuleLine incorrect for inline styles and missing end line/column
Comment 4•10 years ago
|
||
For inline styles, the line returned is line-in-thing-at-the-url (that is, the HTML document), not line-in-style-element. That's the relevant line for things like finding the right line in the document the developer is actually working with. The chance of anything useful happening in this bug if it keeps getting mutated is pretty low, though I suspect it was pretty low to start with. :(
Reporter | ||
Comment 5•10 years ago
|
||
(In reply to Boris Zbarsky [:bz] from comment #4) > For inline styles, the line returned is line-in-thing-at-the-url (that is, > the HTML document), not line-in-style-element. That's the relevant line for > things like finding the right line in the document the developer is actually > working with. Ok, thanks, I didn't know that. > The chance of anything useful happening in this bug if it keeps getting > mutated is pretty low, though I suspect it was pretty low to start with. :( My bad, I should have filed another bug, sorry for that. Perhaps this request isn't the right way of getting the support we need for the devtools, but I think we do need something that we don't have today: getting the stylesheet authored text for a given Rule. Right now the option I'm investigating is: - fetching the stylesheet source (which is wrong in itself, because if the resource hadn't been cached when the page first loaded, the call to the server to get it might send back something different) - extracting the text for the rule I'm interested in, knowing that I have the line/column information for where the rule starts, but I don't know where it stops, so I have to tokenize the content for this. This seems like work the platform could probably help with easily. Any ideas welcome. If my request in comment 0 isn't really what we should be going for, let's close this bug then. Thanks.
Comment 6•10 years ago
|
||
So the basic tradeoff here is that of using more memory for all style rules on the off chance that someone uses devtools to examine them, right? Right now, a StyleRule is 1 word for the vtable, 2 words for Rule, 4 words for selector/declaration/importantrule/domrule, and 8 bytes for the line number, column number, and mWasMatched. That comes out to 36 bytes on 32-bit and 64 bytes on 64-bit. If we want to add end line/column, naively that would add 8 bytes to both of those numbers. If we think we can get away with 23-24 bits for line/column numbers instead of 32 bits, we might be able to get away with just adding 4 bytes. The number of rules on your typical big web page is order of 10000 or so, so this would represent about 40-80KB of memory. That doesn't seem too bad. David, thoughts?
Flags: needinfo?(dbaron)
Summary: DOMUtils css rules location issues: getRuleLine incorrect for inline styles and missing end line/column → New domUtils.getRuleEndLine and domUtils.getRuleEndColumn functions would be useful for the DevTools inspector
At the very least, we can store the end as an offset from the start, and use 16 bits for each. Though it won't really make a difference given the current structure, but probably still worth doing it that way. I guess I'm ok with it. But it really does seem to be getting a little excessive. Are the line and column numbers only used in cases where devtools has the (accurate, no refetching) source of the stylesheet? I was thinking it might be possible to do something involving reparsing the style sheet and storing the line/column information in a secondary structure when asked, but it's hard to associate that with the original style sheet, at least if dynamic changes to the sheet have happened. (Though I suppose we could do that by giving each rule a parse-time-index.)
Flags: needinfo?(dbaron)
Reporter | ||
Comment 8•10 years ago
|
||
(In reply to David Baron [:dbaron] (Away/Busy May 10-22) (UTC+9) from comment #7) > At the very least, we can store the end as an offset from the start, and use > 16 bits for each. Though it won't really make a difference given the > current structure, but probably still worth doing it that way. > > I guess I'm ok with it. But it really does seem to be getting a little > excessive. > > Are the line and column numbers only used in cases where devtools has the > (accurate, no refetching) source of the stylesheet? I was thinking it might > be possible to do something involving reparsing the style sheet and storing > the line/column information in a secondary structure when asked, but it's > hard to associate that with the original style sheet, at least if dynamic > changes to the sheet have happened. (Though I suppose we could do that by > giving each rule a parse-time-index.) We're aiming at providing more and more in-depth information to users of the devtools so they can understand better how css applies, and where problems come from, so we may have more excessive requests in the future. That's why a second reparsing seems better indeed, to avoid storing unnecessary information and slowing down the parsing for 99% of normal users. We're currently talking to the necko team to help with retrieving resources that have been loaded on a page, so if we could then reparse the stylesheets in a sort of devtools-mode to obtain more information, that would be great.
Comment 9•9 years ago
|
||
The as-authored project doesn't need this now, so I am closing it. If we need something like this later, we can reopen or refile. The other request, from comment #2, is bug 1013814.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•