Mozilla/5.0 (Windows NT 5.1; rv:2.0b7pre) Gecko/20100927 Firefox/4.0b7pre ID:20100927041306 repro: open testcase the selectbox content should be in line with the form

Mats, want to take a look?

This bug is about 'translate', bug 455164 'rotate', bug 455170 'scale'. I think they are all the same underlying problem that the CTM isn't applied when painting the dropdown frame. roc suggested looking at GetTransformMatrix in bug 455164, but that's only used for transforming event coordinates afaict. Does anyone know where I should look to fix painting?

nsListControlFrame::BuildDisplayList is where the painting happens. But I think there'd be a lot of other things you'd need to change to.

Actually drawing a rotated or scaled dropdown seems hard. Hacking nsComboboxControlFrame::AbsolutelyPositionDropDown to compute a position that puts the dropdown near where the transformed nsComboboxControlFrame appears should not be hard.

I work on the Google Maps API. Recently, we've disabled the use of CSS transforms in the Maps API on all versions of Firefox due to this bug - <select> drop-downs appear in the untranslated position when placed in an info window and the map is panned. CSS transforms were used to implement, for example, the continuous zoom as one goes from one zoom level to another. Would I be able to ask whether there has been any progress resolving this issue, and perhaps what is the expected time frame for its resolution? Thanks!

I actually have started on this, so stealing.

Here's a hack that fixes this.

Comment on attachment 560261 [details] [diff] [review] patch Review of attachment 560261 [details] [diff] [review]: ----------------------------------------------------------------- I think we should compute the transform-to-root, transform the select frame's bounds by that transform, and then pretend b ::: layout/forms/nsComboboxControlFrame.cpp @@ +524,5 @@ > + } > + nsPoint translation; > + if (!is3DTransform && !transform.HasNonTranslation()) { > + gfxPoint pixelTranslation = transform.GetTranslation(); > + PRInt32 apd = PresContext()->AppUnitsPerDevPixel(); Use "pc" @@ +534,5 @@ > + if (rootPC) { > + translation -= GetOffsetToCrossDoc(rootPC->PresShell()->GetRootFrame()); > + } else { > + translation.x = translation.y = 0; > + } Please put the calculation of this transform into a helper function either in this class or in nsLayoutUtils.

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #9) > I think we should compute the transform-to-root, transform the select > frame's bounds by that transform, and then pretend b What were you trying to say here?

Nothing, just a comment I forgot to delete

Comment on attachment 560642 [details] [diff] [review] patch v2 Review of attachment 560642 [details] [diff] [review]: ----------------------------------------------------------------- ::: layout/forms/nsComboboxControlFrame.cpp @@ +488,5 @@ > return rv; > } > > +nsPoint > +nsComboboxControlFrame::GetCSSTransformTranslate() GetCSSTransformTranslation

http://hg.mozilla.org/integration/mozilla-inbound/rev/cd2472a58eda and to fix up the build for only half fixing the last review comment http://hg.mozilla.org/integration/mozilla-inbound/rev/3610977e5f7e

https://hg.mozilla.org/mozilla-central/rev/cd2472a58eda https://hg.mozilla.org/mozilla-central/rev/3610977e5f7e

Mozilla/5.0 (Windows NT 5.1; rv:9.0a1) Gecko/20110920 Firefox/9.0a1 ID:20110920030905 bug 664707 was set as dupe, however, that issue isn't fixed with this patch. feel free to REclose this one and change dependency/status of bug 664707

I just tested the testcase in bug 664707 and it worked correctly for me. In any case if that bug is still not fixed then reopen it and remove its duplicate status and deps as necessary.

Thanks for all your hard work on this bug - much appreciated!

Bug 713833 covers similar cases for other popups.

Apparently, this bug is back. Confirmed by testing here: http://jsfiddle.net/robreact/7YQ7E/2/ Confirmed in two different mozilla browsers / OS's: Firefox 29.0 - Linux Firefox 35.0.1 - Windows

(In reply to etbz from comment #21) > Apparently, this bug is back. > > Confirmed by testing here: http://jsfiddle.net/robreact/7YQ7E/2/ > > Confirmed in two different mozilla browsers / OS's: > Firefox 29.0 - Linux > Firefox 35.0.1 - Windows That testcase uses scale. This bug is only about translation transforms. Bug 455164 is about supporting transforms other than translation.

With Mac/Firefox 35.0.1, I am seeing select menu options not reflect the translateX setting. Fiddle: https://jsfiddle.net/wragg75/csmLLcg6/1/ The problem can be fixed/forced by toggling the transform property off/on, respectively. Similarly, the problem can be fixed/forced by toggling the perspective property.

The perspective property means that the computed transform matrix for the affected node has more than just 2d components to it, so the matrix is not considered a translation only. Bug 893147 covers selects with perspectice.

I'm seeing this issue when using a style that includes "transform: translate(0px,0px);". When any ancestor div of my flash content includes that style I see a mouse input offset in the flash content. Mouse move, mouse down, mouse up etc. all start hit testing incorrectly. Adding a third 0px in the style fixes the issue. If this bug is left unresolved we will be forced to implement a questionable workaround in our code. This code will be run by roughly 2 million users daily and we would prefer a proper fix to this bug. Please contact me if you need more information jordan.isaman@igt.com.

After more testing I've realized we can't fix this issue with a third 0px.

This bug is about select dropdowns. Not about flash content.

This still seems to be an issue in both FF 42.0 and 44.0a2 (Developer Edition) on Windows 10. May I ask whether there has been any progress since this bug reappeared earlier this year? Thanks for your effort.

If this bug has reappeared then please file a new bug (it is very confusing to track different occurrences of the problem in one bug). Please cc me, include a test case, and mention your OS and any thing else you feel is important to the bug. Thanks.

definitely still not fixed yet, i can still see the problem on this fiddle http://jsfiddle.net/robreact/7YQ7E/2/ and on my site where i am implementing. any workarounds.

Please file a new bug instead of commenting here and cc me please. Thanks.

(In reply to Denford from comment #30) > definitely still not fixed yet, i can still see the problem on this fiddle > http://jsfiddle.net/robreact/7YQ7E/2/ and on my site where i am > implementing. any workarounds. That fiddle has scale transforms. This bug is only about transforms that are translates only.

(In reply to Timothy Nikkel (:tn) from comment #32) > (In reply to Denford from comment #30) > > definitely still not fixed yet, i can still see the problem on this fiddle > > http://jsfiddle.net/robreact/7YQ7E/2/ and on my site where i am > > implementing. any workarounds. > > That fiddle has scale transforms. This bug is only about transforms that are > translates only. i have created a new bug see https://bugzilla.mozilla.org/show_bug.cgi?id=1232824, just was trying to avoid creating duplicates since there is a comment above saying the problem is the same and also there is a few duplicates of the same problem.