Closed Bug 1187482 Opened 5 years ago Closed 5 years ago
Inspector stops showing children of an element if highlighter targets xul:thumb inside its overflow scrollbar
2.52 MB, video/quicktime
9.30 MB, video/quicktime
MozReview Request: Bug 1187482 - Skip XBL and native anonymous content inside non-XUL documents;r=jryans
40 bytes, text/x-review-board-request
STEPS TO REPRODUCE: 1) Load https://bug1187172.bmoattachments.org/attachment.cgi?id=8638275 2) Open devtools 3) Select the "Inspector" tool. 4) Click the triangle next to the <div class="row"> to expand it. 5) Click the "pick an element" button. 6) Mouse over the first cat picture. EXPECTED RESULTS: Can click that picture to get something useful to happen. ACTUAL RESULTS: The kids of the <div class="row"> disappear in the inspector view. Brian, please let me know whether you still need a video showing this happening now that I've added the step 4 in there which you may not have been doing...
Maybe I'm missing a step, but this screencast is on a nightly build on OSX - 42.0a1 (2015-07-27) and I'm not seeing the issue. Tried also in a debug build since I figured you and tromey might have been testing with that, but got the same results.
Chatted with Tom, and it sounds like the STR in the video look right but I'm seeing different results than in his build. Can you reproduce this in a clean profile?
I was definitely testing a regular nightly. I just checked again in a Mac 2015-07-27 nightly and I'm totally seeing the problem. This is the screen recording. I made sure to test with a clean profile, fwiw.
(In reply to Brian Grinstead [:bgrins] from comment #2) > Chatted with Tom, and it sounds like the STR in the video look right but I'm > seeing different results than in his build. Can you reproduce this in a > clean profile? I built today's fx-team and was able to reproduce it with a clean profile. For me it seems to depend on the path the mouse takes to the cat picture. If I move the mouse outside the window, then up vertically, then over the cat, I don't see the bug. But if I move the mouse directly up from the inspector, over other content, then I can reproduce. After experimenting some more the problem seems to arise when the mouse moves over the horizontal scrollbar beneath the cats. According to a tooltip this is a "xul:slider", but it doesn't seem to appear in the document.
(In reply to Tom Tromey :tromey from comment #4) > After experimenting some more the problem seems to arise when the mouse > moves over the horizontal scrollbar beneath the cats. According to a tooltip > this is a "xul:slider", but it doesn't seem to appear in the document. I see, I can reproduce now by scrolling horizontally while inspecting, and then moving the cursor over the visible scrollbar. It does indeed seem that the highlighter is inspecting some anonymous content that it shouldn't be (xul:thumb).
Summary: Inspector stops showing kids of a div in one particular testcase → Inspector stops showing children of an element if highlighter targets xul:thumb inside its overflow scrollbar
Easier STR: 1) Open this page data:text/html,<div style="overflow:scroll;height:50px;width:50px;border:solid 1px;"><div style="height: 100px; width: 100px"></div></div> 2) Press ctrl+shift+c / cmd+shift+c to start inspecting mode 3) Hover over the div and scroll the overflow region around while still inspecting 4) Move the mouse on top of the scrollbar thumb The child element of the parent div disappears
Assignee: nobody → bgrinstead
Status: NEW → ASSIGNED
This is similar to Bug 1093875. Basically, the walker isn't filtering out the XBL anonymous nodes. Unfortunately filtering out XBL content from the walker breaks inspection on the yellow bar on a page like this: http://limpet.net/mbrubeck/atom.xml. In that case the page is somehow embedding XBL content. So we need to be able to distinguish this case from that one.
See Also: → 1093875
I'm fairly sure this is a regression from Bug 1168689, I can't reproduce it in Beta 40 but can in Dev Ed 41
Looks like the feed subscribe page is special cased: https://dxr.mozilla.org/mozilla-central/source/dom/xul/nsXULElement.cpp#796. According to https://dxr.mozilla.org/mozilla-central/source/dom/xul/nsXULElement.cpp?from=isinfeedsubscribeline#873-876 the only places that XUL elements are pulled into content is IsInVideoControls or IsInFeedSubscribeLine. These could probably be special cased in our Walker as well and then simplify our logic for skipping nodes so we can go back to skipping all anonymous elements in a non-XUL document.
Another simple test case: data:text/html,<select multiple><option>1</option><option>1</option><option>1</option><option>1</option><option>1</option><option>1</option><option>1</option><option>1</option></select>
Bug 1187482 - Skip XBL and native anonymous content inside non-XUL documents;r=jryans This will allow the walker to skip scrollbar elements passed in from the highlighter. We used to allow anonymous content just so that feedSubscribeLine contents could be inspected, but that's much less important than the problem it's causing. With this change we still show ::before/::after but nothing else. Note that this doesn't affect the Browser Toolbox at all, which uses another filter.
Attachment #8641689 - Flags: review?(jryans)
Comment on attachment 8641689 [details] MozReview Request: Bug 1187482 - Skip XBL and native anonymous content inside non-XUL documents;r=jryans https://reviewboard.mozilla.org/r/14591/#review13213 Seems to work well in my testing. ::: toolkit/devtools/server/actors/inspector.js:3891 (Diff revision 1) > - if (LayoutHelpers.isNativeAnonymous(aNode) && > + // controls, scrollbars, video controls, etc (see bug 11874820). Nit: Incorrect bug number
Attachment #8641689 - Flags: review?(jryans) → review+
Reproduced this bug in Nightly 42.0a1 (2015-07-24) (Build ID: 20150724030210) on Linux,64 bit with the comment 0's instruction! This Bug is now verified as fixed on Latest Firefox Beta 42.0b7 Build ID 20151015151621 User Agent Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Firefox/42.0
QA Whiteboard: [testday-20151016]
You need to log in before you can comment on or make changes to this bug.