1373994 - Element Picker unusable in Firefox 54 - It's dark and elements can't be selected

Status: RESOLVED WONTFIX

(DevTools :: Inspector, defect, P1)

Description

[vlakoff]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170608105825

Steps to reproduce:

Since Firefox 54, nearly everytime the Element Picker is unusable, I cannot pick the desired element on the page. The selection is staying at some higher lever element and the highlight is grey instead of being colorful.

The issue happens randomly, but almost everytime, and the loaded page is either working or broken, i.e. the picker may be fixed by reloading the page.

Comment 1

[stefano]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170608105825

I have the same problem. It seems to happen when resizing the browser window.
Websites with elements that are position: fixed; seems to trigger this problem more frequently.
Sometimes when loading a page without resizing this bug happens.

With Firefox Developer Edition (55) this bug doesn't seems to appear.

Comment 2

[stefano]

About the position: fixed it seems that some websites are working ok even when resizing, but I found how to reproduce this bug.

Steps to reproduce:

1. Load the website
https://webdesign.tutsplus.com/tutorials/silky-smooth-web-animation-with-velocityjs--cms-24266

2. Open the devtools and with the Element picker hover onto some elements (it works ok)
3. Resize the browser window
4. If you use now the Element Picker, it is broken, and some elements are shown in a dark color.

Comment 3

[Patrick Brosset <:pbro>]

I was able to reproduce this bug with Firefox 54, on the site given in comment 2. But it's random as comment 0 suggests. I'm not able to make it fail again now that I've restarted DevTools.

One way I found was: 
- start Firefox
- load the page
- while it loads, open the inspector
- wait until you can pick elements

For some reason, this site takes ages to load when the inspector is opened. Maybe something goes wrong during that phase.

This problem does, indeed, seem to be fixed in 55 and up.

The fact that the highlighter is dark instead of its usual colors makes me think that the CSS of the highlighter isn't loaded properly.
Note however that the margin color (yellow) and padding color (purple) do seem to work. Only the content area is dark, and the nodeinfobar is misplaces.

Also, moving the mouse over the page does not highlight the elements being hovered. This could also come from the missing stylesheet since it defines pointer-events: none; on the highlighter. So if that's missing, then the highlighter itself blocks events from reaching content elements.

Matteo, any idea about what could be happening?

Comment 4

[id]

Confirm the problem and that it seems to be solved.  Running Win64.
- 53.0.3 working fine.
- 54 Win64 I see the bug.  It is somewhat random, but I see it a lot.
- 55.0b5 working fine so far.

If the OP can confirm that 55b works fine then we can potentially close the issue.

Comment 5

[vlakoff]

I just did a quick try with 55.0b5 and a fresh profile. At first glance it seems to work.

Comment 6

[vlakoff]

54.0.1 has been released meanwhile, and it seems to be fixed too :)

Comment 7

[stefano]

Unfortunately the bug is still present in Firefox 54.0.1 (64 bit macOS).
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:54.0) Gecko/20100101 Firefox/54.0
ID build 20170628075643

The bug is triggered when selecting something with the element picker, then resizing the browser window and again re-select something else.

Comment 8

[vlakoff]

I managed to reproduce the bug too:

* using 54.0.1 (haven't tried 55.0)
* on the website of comment #2 (https://webdesign.tutsplus.com/tutorials/silky-smooth-web-animation-with-velocityjs--cms-24266)
* resizing the browser window as you described

Comment 9

[Patrick Brosset <:pbro>]

We need some activity on this very quickly. This impacts all our release users. If someone has time to do a regression window, that would really great!

Comment 10

[Tim Nguyen :ntim]

This happens more often when switching to an HTML iframe (netmonitor for example) from the browser toolbox. You can see black squares instead of the highlighter.

Just thought I'd mention it because it's easier to reproduce for me, and it might be the same issue ?:
- Open the network monitor (or any HTML based tool) in one of the browser tabs
- Open the browser toolbox
- Switch to the netmonitor frame with the toolbox frame switcher functionality
- Try to highlight stuff using the browser toolbox

Comment 11

[Patrick Brosset <:pbro>]

Happens all the time for me, on a release build of 54. I just open about:home, open the inspector, and hover over nodes in the inspector.
I tested nightly builds of 54, no problem there.
I tested release builds of 53 (like 53.0b10, 53.0.3, etc.) no problem there either. So there's something in 54 that changed, only in release, that is causing this issue.

Comment 12

[Matteo Ferretti [:zer0] [:matteo]]

Happens all the time for me too (OS X), I sent an email to Brad asking take a look on this, since it might be related to something on layout / platform side; even if it's not, I'm pretty sure his help will provide more insight about this matter.

I suspect that it could be some regression on the anonymous content on platform side since:

1. Once it's happens for me, the behavior become persistent.
It means, even if I kill all the devtools code, I close the tab, the window, open a new one, and therefore recreate everything by scratch, the issue is there already, even without the need to do the steps to reproduce it.

2. I got a lot of the same error related to GFX, saying that "GPU process might be dead".

3. I also got it when I restarted the browser (!)

Comment 13

[vlakoff]

Please disregard my comment #6, actually I'm still encountering this issue a lot on Firefox 54.0.1.

If this may help to track it down, I am using Firefox with hardware acceleration disabled (gfx.direct2d.disabled and layers.acceleration.disabled)

Comment 14

[Brad Werth [:bradwerth]]

I'm working to get a debug build of 54.0.1 build running so I can root cause this, currently hitting an issue reported in Bug 1379807.

Comment 15

[Brad Werth [:bradwerth]]

I can reproduce, but I don't have any insight into what's going wrong. For me, on OS X, it's consistently reproducible with an about:home tab and going straight to the Inspector with the key command (Command-Option-C).

Comment 16

[Brad Werth [:bradwerth]]

Without insight into what's causing the problem (no useful error logs that I can see), I'm resorting to bisecting the changesets to find the relevant patch.

Comment 17

[cr7-rm]

Confirmed. The inspector is unusable when this problem appears.

You can fix it with closing and reopening the dev tools but it is really annoying.

It mostly appears when inspecting complex pages with a bigger DOM.

Comment 18

[Brad Werth [:bradwerth]]

Bisecting the regression is going slowly. There are no testable builds on mozilla-release between FF 53.0.4 and FF 54, and the problem does not show up for me on corresponding changesets on mozilla-central (which would give us Nightly builds testable with the mozregression tool). So I'm resorting to doing manual builds bisecting these changesets: https://hg.mozilla.org/releases/mozilla-release/pushloghtml?startdate=2017-06-05&enddate=2017-06-28. I've narrowed the regression down to the region between:

last known good: https://hg.mozilla.org/releases/mozilla-release/rev/eb8eade361cb
first known bad: https://hg.mozilla.org/releases/mozilla-release/rev/19b457181440

which is a range of 872 changesets. Each build is taking me about an hour. Maximum throughput means I'll find it in 10 hours.

Comment 19

[vlakoff]

Thank you Brad for your work on this.

As a workaround, one can resize the developer pane so that it partly covers the desired element, then activate the element picker mode, and move the mouse from the developer pane directly to the element, so that the mouse doesn't hover over any other element.

Comment 20

[Brad Werth [:bradwerth]]

I cheated a bit and made some educated bisections based on the commit messages. Range is now the 14 changesets between:

good: https://hg.mozilla.org/releases/mozilla-release/rev/da3f4f145b69
bad: https://hg.mozilla.org/releases/mozilla-release/rev/8bad8b5fcd98

And the culprit is almost certainly this changeset: https://hg.mozilla.org/releases/mozilla-release/rev/7c2f76488221. It will take me a few more hours to prove it, but this is the one.

That changeset calls the AnonymousContent.getComputedStylePropertyValue function that was added a few changesets before at https://hg.mozilla.org/releases/mozilla-release/rev/6de2c310ebe8. Something has gone wrong with this call usage. I'm not familiar enough with the correct calling pattern, so I'm moving the needinfo.

Comment 21

[Brad Werth [:bradwerth]]

(In reply to Brad Werth [:bradwerth] from comment #20)
> And the culprit is almost certainly this changeset:
> https://hg.mozilla.org/releases/mozilla-release/rev/7c2f76488221. It will
> take me a few more hours to prove it, but this is the one.

I've completed the bisection. This changeset introduces the problem: https://hg.mozilla.org/releases/mozilla-release/rev/7c2f76488221 . I can't get the same changeset to show the problem on mozilla-central, so there's something subtle happening here. I don't really know how changesets get merge from m-c into release, but I can't determine which changeset fixes the problem.

Comment 22

[Matteo Ferretti [:zer0] [:matteo]]

Thanks for the bisection, Brad!

So, I don't think this code is the culprit per se, since if that was the case, we should still have this issue after Firefox 54.
But, it's true that introduced the usage of AC's `getComputedStylePropertyValue` in DevTools, so it might have introduced indirectly some bug that it was present in the `getComputedStylePropertyValue` implementation, and it was fixed after.

If it helps, here the patch that implemented `getComputedStylePropertyValue`:

https://reviewboard.mozilla.org/r/121066/diff/2#index_header

I remember also that we landed only this patch of three (see bug 1346623) immediately; so is it possible that lands only this cause the glitch that was fixed once all of them landed? Or it could be something else, but I guess at least now we know where to look.

Comment 23

[Brad Werth [:bradwerth]]

If you know that this is patch 1 of 3, then I can test the application of parts 2 and 3 to see if they resolve the problem. What are the other two patches?

Comment 24

[Matteo Ferretti [:zer0] [:matteo]]

(In reply to Brad Werth [:bradwerth] from comment #23)
> If you know that this is patch 1 of 3, then I can test the application of
> parts 2 and 3 to see if they resolve the problem. What are the other two
> patches?

They shouldn't be related, at least that was the person wrote the code said, one I think it's just the tests. The patches are all listed in bug 1346623's attachments.

Comment 25

[Brad Werth [:bradwerth]]

Attachment: Bug 1373994 - Part 1: Prevent canvas custom content from becoming NAC when reframing the root element.

Review commit: https://reviewboard.mozilla.org/r/163488/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/163488/

Comment 26

[Brad Werth [:bradwerth]]

Thanks Matteo, I've confirmed that the first part of the patches for Bug 1346623 is sufficient to fix the problem. I've repackaged that change as a patch on this bug.

Comment 27

[Bobby Holley (:bholley)]

Comment on attachment 8892514 [details]
Bug 1373994 - Part 1: Prevent canvas custom content from becoming NAC when reframing the root element.

https://reviewboard.mozilla.org/r/163488/#review168870

IIUC this is already fixed in 55, which will be released within days. It seems extremely unlikley that we would respin 54 over this, at which point the issue is moot.

Comment 28

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

This is a P1 bug without an assignee. 

P1 are bugs which are being worked on for the current release cycle/iteration/sprint. 

If the bug is not assigned by Monday, 28 August, the bug's priority will be reset to '--'.