Last Comment Bug 664707 - Unable to use drop-down list (<select>) in a div with transform:translate
: Unable to use drop-down list (<select>) in a div with transform:translate
Status: RESOLVED FIXED
: css-moz, testcase
Product: Core
Classification: Components
Component: Layout: Form Controls (show other bugs)
: Trunk
: x86 Windows 7
: -- major with 6 votes (vote)
: mozilla13
Assigned To: Timothy Nikkel (:tnikkel)
:
Mentors:
: 733209 747081 (view as bug list)
Depends on: 599938
Blocks: 700975 708407 759993
  Show dependency treegraph
 
Reported: 2011-06-16 06:29 PDT by Herb Warren
Modified: 2013-03-28 23:46 PDT (History)
15 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
HTML testcase showing the offset contents (568 bytes, text/html)
2011-06-16 06:32 PDT, Herb Warren
no flags Details
Screenshot (74.33 KB, image/png)
2011-06-16 07:13 PDT, AndreiD[QA]
no flags Details
patch (2.59 KB, patch)
2012-03-03 01:21 PST, Timothy Nikkel (:tnikkel)
mats: review+
Details | Diff | Review
followup (1.57 KB, patch)
2012-03-05 17:15 PST, Timothy Nikkel (:tnikkel)
wjohnston2000: review+
mats: review+
Details | Diff | Review

Description Herb Warren 2011-06-16 06:29:52 PDT
User-Agent:       Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.20 Safari/535.1
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

If a form with a <select> is inside a div that has had a transform:translate applied to it, the form renders correctly, but the drop-down list contents will not be displayed where expected - the list is not translated properly.

Reproducible: Always

Steps to Reproduce:
1. Create a blank page with a div with a transform:translate in the style attribute
2. Add a form with select and options tags contained in the div
3. Show the form in FF4


Actual Results:  
Page renders with the contents of the drop-down list not correctly translated

Expected Results:  
All contents (including drop-down listing) correctly translated

Test case to be attached. 

Note that this is not a completely academic exercise - Google Maps API uses -moz-transform:translate extensively, and their infowindows (balloon pop-ups) are inside the translated <div>. This prevents anyone from using a <select> in the infowindows.
Comment 1 Herb Warren 2011-06-16 06:32:16 PDT
Created attachment 539784 [details]
HTML testcase showing the offset contents
Comment 2 Herb Warren 2011-06-16 06:41:09 PDT
Note that this behavior is also apparent in FF 3.6, and 5b5 (have not tested on 5b7)
Comment 3 AndreiD[QA] 2011-06-16 07:10:40 PDT
I could reproduce the issue on the latest Nightly:
 Mozilla/5.0 (Windows NT 6.1; rv:7.0a1) Gecko/20110615 Firefox/7.0a1

This bug could be set on NEW. Attaching a screenshot of the issue.
It could be a code incompatibility issue.
Comment 4 AndreiD[QA] 2011-06-16 07:13:04 PDT
Created attachment 539789 [details]
Screenshot
Comment 5 Herb Warren 2011-06-16 07:14:22 PDT
Crud - this is possibly a duplicate of:
https://bugzilla.mozilla.org/show_bug.cgi?id=599938

Apologies - I didn't find this before.
Comment 6 AndreiD[QA] 2011-06-16 07:16:21 PDT
(In reply to comment #5)
> Crud - this is possibly a duplicate of:
> https://bugzilla.mozilla.org/show_bug.cgi?id=599938
> 
> Apologies - I didn't find this before.

Thanks for the notice

*** This bug has been marked as a duplicate of bug 599938 ***
Comment 7 Peter van der Woude [:Peter6] 2011-09-20 11:04:06 PDT
this wasn't fixed by the patch of bug Bug 599938
It's a bit unclear if it depends or blocks the other one because I can't tell if they're not 2 sepatate issues
Comment 8 Timothy Nikkel (:tnikkel) 2011-09-20 11:06:06 PDT
I am not able to reproduce this issue, I tested the attached testcase with the latest nightly on Linux and Windows XP. How do you reproduce this?
Comment 9 Alice0775 White 2011-09-20 11:12:21 PDT
Position of the dropdown list is OK
However, I cannot select an option  by mouse click. And No highlight by mouse hover

Tested on
http://hg.mozilla.org/mozilla-central/rev/648d084ca28e
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0a1) Gecko/20110920 Firefox/9.0a1 ID:20110920030905
Comment 10 Timothy Nikkel (:tnikkel) 2011-09-20 11:20:04 PDT
Ah, its about being able to interact with the dropdown, that's why I wasn't able to reproduce. Thanks Alice.
Comment 11 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-09-20 12:48:11 PDT
Does that mean that bug 599938 actually caused a regression because we can't interact with transformed <select> dropdowns?

If so, we should probably back it out and re-fix it.
Comment 12 Mounir Lamouri (:mounir) 2011-09-20 12:58:45 PDT
No, with Firefox 6 the dropdown is mis-placed *and* the user can't interact with it. If it's now placed correctly, it's an improvement.
Comment 13 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-09-20 14:27:30 PDT
Great!
Comment 14 Enoch Lau 2012-01-23 21:41:35 PST
Hi Timothy, thanks again for fixing bug 599938; <select> elements that have been transformed indeed appear in the right place on Firefox 9.

However, because users can't interact with <select> elements that have been translated (which is the subject of this bug), the Google Maps API is still unable to use CSS transforms for things like continuous zoom on Firefox.

Would I be able to ask if you've had any progress with this particular issue?

Thanks again!
Comment 15 Timothy Nikkel (:tnikkel) 2012-01-24 00:41:28 PST
I'm sorry, I haven't had any time to work on this. If anybody wants to look into this they are welcome to take it from me.
Comment 16 Timothy Nikkel (:tnikkel) 2012-03-02 04:00:44 PST
So when you try to transform the mouse events coordinates to be relative to the list control frame that forms the dropdown we end up transform the coordinates *twice* by the transform: once for the frame that actually has the transform, and then the regular old position of the list control frame is also offset by the transform due to the patch in bug 599938.
Comment 17 Peter van der Woude [:Peter6] 2012-03-02 04:33:19 PST
setting importance normal->major because it doesn't work at all while giving the user the illusion it should.
Comment 18 Timothy Nikkel (:tnikkel) 2012-03-03 01:21:43 PST
Created attachment 602585 [details] [diff] [review]
patch

I thought about different ways of fixing the problem described in comment 16 but none of them were very good.

This is what I settled on. The code duplication will be fixed once bug 722965 lands.

We call GetEventCoordinatesRelativeTo from PresShell::HandleEvent for all mouse events. In the common case the frame we pass is the root frame for the widget of the event. So instead of going through the full generality we can skip it for the simple common case. The side benefit from this (and the reason it fixes this bug) is that we no longer need to transform event coordinates of popups into root frame coordinates of the parent window and then right back into popup coordinates.

It's not ideal, but it works and seems to be the least objectionable way to fix this bug.
Comment 19 Mats Palmgren (:mats) 2012-03-03 04:04:03 PST
Comment on attachment 602585 [details] [diff] [review]
patch

r=mats but I think we need a code comment pointing out that it's also needed
for correctness with a reference to this bug.  If I didn't know the background
and read this block I would assume it's just an optimization.
Comment 20 Timothy Nikkel (:tnikkel) 2012-03-03 13:21:29 PST
(In reply to Mats Palmgren [:mats] from comment #19)
> r=mats but I think we need a code comment pointing out that it's also needed
> for correctness with a reference to this bug.  If I didn't know the
> background
> and read this block I would assume it's just an optimization.

Good point. I made it read:

      // Special case this cause it happens a lot.
      // This also fixes bug 664707, events in the extra-special case of select
      // dropdown popups that are transformed.
Comment 21 Timothy Nikkel (:tnikkel) 2012-03-03 13:25:07 PST
https://hg.mozilla.org/integration/mozilla-inbound/rev/9fbe111ef1c3
Comment 22 Ed Morley [:emorley] 2012-03-04 15:27:58 PST
https://hg.mozilla.org/mozilla-central/rev/9fbe111ef1c3
Comment 23 Timothy Nikkel (:tnikkel) 2012-03-05 17:15:26 PST
Created attachment 603118 [details] [diff] [review]
followup

wesj pointed out that I am using the wrong point in the second version of this function. The point of the second version is to use the passed in point and not the events refpoint. I also fixed up the name of an identifier that snuck through.
Comment 24 Wesley Johnston (:wesj) 2012-03-05 17:17:42 PST
Comment on attachment 603118 [details] [diff] [review]
followup

Thanks!
Comment 25 Timothy Nikkel (:tnikkel) 2012-03-05 17:19:50 PST
Comment on attachment 603118 [details] [diff] [review]
followup

Whoops, I meant to ask for Mats review.
Comment 26 Timothy Nikkel (:tnikkel) 2012-03-06 08:21:20 PST
Followup
https://hg.mozilla.org/integration/mozilla-inbound/rev/6942914bc8c1
Comment 27 Marco Bonardo [::mak] 2012-03-07 02:24:31 PST
https://hg.mozilla.org/mozilla-central/rev/6942914bc8c1
Comment 28 Mark Finkle (:mfinkle) (use needinfo?) 2012-03-08 10:17:04 PST
*** Bug 733209 has been marked as a duplicate of this bug. ***
Comment 29 Timothy Nikkel (:tnikkel) 2012-04-19 15:49:24 PDT
*** Bug 747081 has been marked as a duplicate of this bug. ***
Comment 30 Enoch Lau 2012-07-16 04:16:16 PDT
Timothy, thanks for taking a look at this bug. If I understand correctly, this fix should've gone out in Firefox 13, which is now in the release channel.

There still appears to be a problem with <select> elements that have been css transformed. You can click on them to open the drop-down, and if you mouse over elements in the drop-down, they get highlighted. But clicking on the elements in the drop-down doesn't work; it doesn't get selected.

To see this, open the attachment on https://bugzilla.mozilla.org/show_bug.cgi?id=747081 (a dupe of this bug): https://bug747081.bugzilla.mozilla.org/attachment.cgi?id=616651
Click on the drop-down and try to select "two" - you can't.

I've verified this using Firefox 13.0.1 on Mac and Linux.
Comment 31 Alice0775 White 2012-07-16 04:40:05 PDT
>There still appears to be a problem with <select> elements that have been css transformed. 
>You can click on them to open the drop-down, and if you mouse over elements in the drop-down, 
>they get highlighted. But clicking on the elements in the drop-down doesn't work; it doesn't get selected.

I can reproduce with attachment 539784 [details] in
http://hg.mozilla.org/mozilla-central/rev/57abb5f70e01
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120715030544
http://hg.mozilla.org/releases/mozilla-aurora/rev/50963e16d1dc
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120715 Firefox/15.0a2 ID:20120715042008
http://hg.mozilla.org/releases/mozilla-beta/rev/8b97fc666642
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0 ID:20120710123126
http://hg.mozilla.org/releases/mozilla-release/rev/f48d675ffa9f
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0.1 ID:20120614114901


Re-Opend
Comment 32 Timothy Nikkel (:tnikkel) 2012-07-16 06:52:16 PDT
You are correct, the fix here improved the situation, but I didn't notice that you still can't click and select items. We're going to track that remaining issue in bug 759993. We'll keep this resolved since a patch landed and it improved the situation.
Comment 33 Enoch Lau 2012-07-16 07:01:52 PDT
Alright, thanks. I'll follow that other bug for updates.
Comment 34 Monica Nguon 2012-11-13 06:23:21 PST
I can still reproduce this bug with attachment 539784 [details].

Ubuntu 12.04.1 LTS
Firefox 16.0.2
Comment 35 Peter van der Woude [:Peter6] 2012-11-13 06:33:08 PST
(In reply to Monica Nguon from comment #34)
> I can still reproduce this bug with attachment 539784 [details].
> 
> Ubuntu 12.04.1 LTS
> Firefox 16.0.2

the ramaining issue, as you decribe, is Bug 759993
Comment 36 Monica Nguon 2012-11-13 06:43:49 PST
I tried the test cases attached to bugs 747081, 664707 and 759993: none of them seems to be working in my browser.

Moreover, the test cases are slightly different:
* Attachment 616651 [details] from bug 747081: select with translate in the style attribute: not working.
* Attachment 539784 [details] from bug 664707 (this bug): select with translate on the select parent: not working but see next line.
* Attachment 628597 [details] from bug 759993: select with translate on parent's parent; not working (but still opened).
Comment 37 Monica Nguon 2012-11-13 08:28:13 PST
Not sure if Bugzilla is the place where to ask this question, but in the eventuality of a 16.0.3 release including the correction for this issue, how are we supposed to handle this issue on older Firefox versions? Is there a workaround that we should apply to our websites so that they will display correctly in previous browser versions?
Comment 38 Timothy Nikkel (:tnikkel) 2012-11-13 11:05:19 PST
Like Peter said the remaining issues here are covered by bug 759993.

It is highly unlikely any Firefox 16 release would fix these issues.
Comment 39 yair even or 2013-03-28 10:31:36 PDT
This is still happening on MAC....this is serius bug in my opinion, and one easy to fix.
Comment 40 Timothy Nikkel (:tnikkel) 2013-03-28 12:03:24 PDT
(In reply to yair even or from comment #39)
> This is still happening on MAC....this is serius bug in my opinion, and one
> easy to fix.

What version are you using? Please file a new bug.
Comment 41 Timothy Nikkel (:tnikkel) 2013-03-28 12:08:35 PDT
You're probably seeing bug 829886 which will be fixed in Firefox 20.
Comment 42 yair even or 2013-03-28 23:44:46 PDT
No, I see THIS same bug discussed in here...
The FF version is 19 on the mac i'm seeing this right now.
Comment 43 Timothy Nikkel (:tnikkel) 2013-03-28 23:46:59 PDT
I think the problem you are seeing will be fixed in Firefox 20. The good news is that you can test that right now by downloading Firefox Beta (or Aurora or Nightly) or you can just wait until it is released. Either way if you find the the problem you are seeing is not fixed in Firefox 20 then please file a new bug.

Note You need to log in before you can comment on or make changes to this bug.