1351063 - Eyedropper doesn't follow mouse cursor if CSS 'transform' is applied in iframe

Status: NEW

(DevTools :: Inspector, defect, P3)

Description

[684sigma]

I have a problem with Firefox Beta 52. It also happens in Beta 53, Nightly 55. Doesn't happen in ESR 45.
On some sites I noticed a very weird behavior: eyedropper moves incorrectly, as if mouse cursor was placed in a different area. I experimented a bit, and created a working example of the bug.
I'll check those sites once this bug is fixed. Here's how to reproduce the bug:

1. Open attachment 8851747 [details]
2. Open devtools, click on eyedropper button in inspector.
3. Move mouse cursor to the iframe, move mouse within iframe.

Result: Eyedropper appears far away from mouse.
Expected: Eyedropper should follow mouse cursor.

Another bug detected with that page is bug 1351062.

Comment 1

[Stefan [:StefanG_QA]]

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0

I have tested your issue on latest FF release (52.0.1), latest Nightly build (20170328030207) and managed to reproduce it. If I navigate the mouse cursor to the top left corner the issue is not observed, but when I moved it to the right I can see that eyedropper appears far away from the expected location.

Comment 2

[Stefan [:StefanG_QA]]

Last good revision: f44bb9de08ade45299223de89953c6d0f4d003d1
First bad revision: e730a1dca1a41bd6b0824353305abc25284e2d52
Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f44bb9de08ade45299223de89953c6d0f4d003d1&tochange=e730a1dca1a41bd6b0824353305abc25284e2d52

From the pushlog it appear to works like that since it was initially introduced in Nightly 50.0a1 build.

Comment 3

[Patrick Brosset <:pbro>]

(In reply to Stefan [:StefanG_QA] from comment #2)
> Last good revision: f44bb9de08ade45299223de89953c6d0f4d003d1
> First bad revision: e730a1dca1a41bd6b0824353305abc25284e2d52
> Pushlog:
> https://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=f44bb9de08ade45299223de89953c6d0f4d003d1&tochange=e730
> a1dca1a41bd6b0824353305abc25284e2d52
> 
> From the pushlog it appear to works like that since it was initially
> introduced in Nightly 50.0a1 build.
Thanks for the pushlog. Yes, this is basically an issue with the original implementation done in bug 1262439.
I don't think it should be a big deal to fix, but I would probably mark 53 and 54 as wontfix too. We might try and get it in 55 if we have time, but this isn't severe enough that we will risk and uplift it as far as we can.

Comment 4

[Liz Henry (:lizzard) (relman/hg->git project)]

Too late for a fix for 53, fix-optional for 54, minor carryover regression.