See attached testcase. Seems a lot like bug 664707 but is totally happening in current builds.

Hmm, weird, the highlight follows the mouse correctly, but mouse clicks don't seem to get through properly.

This looks like it's still what I reported on bug 747081 and got closed as a duplicate of bug 664707. The bug I opened contains a link to a jsfiddle that lets you programatically check the existence of this bug.

Here it is as a jsfiddle http://jsfiddle.net/fGMG7/ if it helps.

Here's a simplified test case from me: http://jsfiddle.net/xawDt/ This bug affects Leaflet JS maps library http://leaflet.cloudmade.com/ (since popups are positioned with transforms for smoother animations).

I'm on the Google Maps API team, and we've disabled the use of CSS transforms in Firefox because of this bug, which unfortunately degrades the experience (by disabling continuous zoom). Thanks for making improvements in the past, but until transformed select elements work perfectly, it unfortunately isn't much use.

For consistency, here's the fiddle I referenced in the above comment: http://jsfiddle.net/gonchuki/vxS3L/1/ For anyone with this issue, be sure to check against this bug using this snippet instead of doing browser sniffing. As I found out, this is still the most reliable way to detect if a browser pesents this bug (and can come handy as a unit test for whoever is fixing it in Firefox itself)

(In reply to gonchuki from comment #7) > For consistency, here's the fiddle I referenced in the above comment: > http://jsfiddle.net/gonchuki/vxS3L/1/ > > For anyone with this issue, be sure to check against this bug using this > snippet instead of doing browser sniffing. As I found out, this is still the > most reliable way to detect if a browser pesents this bug (and can come > handy as a unit test for whoever is fixing it in Firefox itself) The fix for this bug is most likely not going to change the value of offsetTop. So this check is not a reliable way to probe for this bug existing.

The fix should change it, as the offsetTop for the transformed option *matches* the invisible hit area that it's taking (and not the visible rendered part of it). Check it with firebug on http://jsfiddle.net/xawDt/, if you open the select and go into the HTML pane and hover the <option> tags you will see that the options themselves got translated again, using the same transform that their parent had (thus, the transform is applied twice, and the first option element is for example at 100px left instead of the 50px the select has.) To be clear: the offsetTop of each option element is currently incorrect, and that's what my snippet asserts. Fixing the hit area MUST also fix the reported offsetTop of each option element, else Firefox will remain broken.

(In reply to gonchuki from comment #9) > The fix should change it, as the offsetTop for the transformed option > *matches* the invisible hit area that it's taking (and not the visible > rendered part of it). > > Check it with firebug on http://jsfiddle.net/xawDt/, if you open the select > and go into the HTML pane and hover the <option> tags you will see that the > options themselves got translated again, using the same transform that their > parent had (thus, the transform is applied twice, and the first option > element is for example at 100px left instead of the 50px the select has.) > > To be clear: the offsetTop of each option element is currently incorrect, > and that's what my snippet asserts. Fixing the hit area MUST also fix the > reported offsetTop of each option element, else Firefox will remain broken. I think this is a separate issue. Please file a new bug on it.

It's one single bug, I can't understand why you insist on the fact that fixing this bug will somehow keep reporting incorrect coordinates for the option element. The option element *is* at an incorrect offset, and that's not something that you simply measure with code or the mouse pointer not working on the visible area, you can actually SEE the thing at the incorrect offset with the aid of firebug: http://sandbox.gonchuki.com/files/highlight_broken_hit_area.png Now, this area is an exact match of the coordinates reported via offsetLeft and offsetTop. It's not a coincidence or a "different bug", it's simply measuring a fact, the fact that this element is positioned wrong.

I think the problem is in nsLayoutUtils::GetTransformToAncestor, combined with the fix for bug 599938. In bug 599938 we set the popup frame's offset to a destination that includes translation transforms from its ancestors in the page. But nsLayoutUtils::GetTransformToAncestor called on the popup frame will add up the popup frame's offset along with the ancestor translations, effectively applying the ancestor translations twice. This causes event coordinates to be miscalculated.

I wonder why the coordinates of mouse moves are interpreted fine (the selection correctly follows your mouse as you mouse over) but mouse clicks aren't.

I think because GetFrameForPoint works, so the correct elements are targeted by events, but nsLayoutUtils::GetDOMEventCoordinatesRelativeTo doesn't work because it relies on nsIFrame::GetTransformMatrix.

Comment on attachment 674628 [details] [diff] [review] v2, slightly more robust to popups without widgets >+ gfx3DMatrix result; >+ result._41 = translation.x; >+ result._42 = translation.y; >+ *aOutAncestor = nullptr; >+ return result; Hmm, shouldn't aOutAncestor be the root root frame here and not null?

Yes, OK.

This patch causes numerous test failures, e.g. https://tbpl.mozilla.org/php/getParsedLog.php?id=16682640&tree=Try&full=1#error0 Lots of ###!!! ASSERTION: Ancestors for popups not supported: '!aStopAtAncestor', file ../../../layout/generic/nsFrame.cpp, line 4767

This patch should help prevent those assertions.

Unfortunately this patch causes failures in test_arrowpanel.xul because in some cases getBoundingClientRect is called right after we've created and positioned a popup, but before widget changes have been flushed. Because of the delayed widget positioning, I think the approach of this patch is pretty much wrong.

Do we actually move XUL popups based on CSS transforms? Can we just handle select dropdowns here?

Yeah, let's do that for now.

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #27) > https://tbpl.mozilla.org/?tree=Try&rev=5487de940465 Looking at that patch you might want to update the condition in the while at the bottom of the patch to limit it to selects as well as the if at the top.

(In reply to Timothy Nikkel (:tn) from comment #28) > Looking at that patch you might want to update the condition in the while at > the bottom of the patch to limit it to selects as well as the if at the top. I think it's actually fine to stop wherever we want there.

https://hg.mozilla.org/integration/mozilla-inbound/rev/cf1080d1f8b3 https://hg.mozilla.org/integration/mozilla-inbound/rev/342ebbbb736b

https://hg.mozilla.org/mozilla-central/rev/cf1080d1f8b3 https://hg.mozilla.org/mozilla-central/rev/342ebbbb736b

Just attempted to use the attached testcase, and this does not work in Nightly 21.0a1 (2013-01-11). Re-opening. This is pretty nasty.

Hmm, it seems the patch has fixed the problem for Windows and Linux, but not Mac. I think we should file a new bug for that.

I filed bug 829886 for that.

Verified fixed FF 20b2 Win 7, Ubuntu 12.04.