Closed Bug 599938 Opened 14 years ago Closed 13 years ago

TRANSLATION ONLY TRANSFORMS moz-transform:translate shows select dropdown content on non-translated position

Categories

(Core :: Layout: Form Controls, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla9

People

(Reporter: Peter6, Assigned: tnikkel, NeedInfo)

References

Details

(Whiteboard: [DON'T COMMENT IF YOUR TRANSFORM HAS SOMETHING OTHER THAN TRANSLATES][this probably isn't the bug you are seeing])

Attachments

(2 files, 1 obsolete file)

Attached file testcase (deleted) —
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.
Hardware: x86 → All
Blocks: 669887
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.
Assignee: matspal → tnikkel
Attached patch patch (obsolete) (deleted) — Splinter Review
Here's a hack that fixes this.
Attachment #560261 - Flags: review?(roc)
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.
Attachment #560261 - Flags: review?(roc) → review+
(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
Attached patch patch v2 (deleted) — Splinter Review
Attachment #560261 - Attachment is obsolete: true
Attachment #560642 - Flags: review?(roc)
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
Attachment #560642 - Flags: review?(roc) → review+
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla9
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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
Status: REOPENED → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
Blocks: 664707
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.
Summary: moz-transform:translate shows selectbox content on non-translated position → moz-transform:translate shows select dropdown content on non-translated position
Whiteboard: [this probably isn't the bug you are seeing]
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.
Flags: needinfo?(dev)
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.
Flags: needinfo?(babybwoy2001)
(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.
Flags: needinfo?(babybwoy2001)
Summary: moz-transform:translate shows select dropdown content on non-translated position → TRANSLATION ONLY TRANSFORMS moz-transform:translate shows select dropdown content on non-translated position
Whiteboard: [this probably isn't the bug you are seeing] → [DON'T COMMENT IF YOUR TRANSFORM HAS SOMETHING OTHER THAN TRANSLATES][this probably isn't the bug you are seeing]
(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.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: