The default bug view has changed. See this FAQ.

Unable to use drop-down list (<select>) in a div with transform:translate

RESOLVED FIXED in mozilla13

Status

()

Core
Layout: Form Controls
--
major
RESOLVED FIXED
6 years ago
4 years ago

People

(Reporter: Herb Warren, Assigned: tnikkel)

Tracking

({css-moz, testcase})

Trunk
mozilla13
x86
Windows 7
css-moz, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments)

(Reporter)

Description

6 years ago
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.
(Reporter)

Comment 1

6 years ago
Created attachment 539784 [details]
HTML testcase showing the offset contents
(Reporter)

Comment 2

6 years ago
Note that this behavior is also apparent in FF 3.6, and 5b5 (have not tested on 5b7)
Keywords: css-moz, testcase
Version: unspecified → 2.0 Branch

Comment 3

6 years ago
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 4

6 years ago
Created attachment 539789 [details]
Screenshot

Updated

6 years ago
OS: Windows XP → Windows 7
Version: 2.0 Branch → Trunk
(Reporter)

Comment 5

6 years ago
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

6 years ago
(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
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 599938
(Assignee)

Updated

6 years ago
Attachment #539784 - Attachment mime type: text/plain → text/html
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
Status: RESOLVED → REOPENED
Depends on: 599938
Resolution: DUPLICATE → ---
(Assignee)

Comment 8

6 years ago
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

6 years ago
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
(Assignee)

Comment 10

6 years ago
Ah, its about being able to interact with the dropdown, that's why I wasn't able to reproduce. Thanks Alice.
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.
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.
Great!
Assignee: nobody → tnikkel

Comment 14

5 years ago
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!
(Assignee)

Comment 15

5 years ago
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.
(Assignee)

Comment 16

5 years ago
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.
setting importance normal->major because it doesn't work at all while giving the user the illusion it should.
Severity: normal → major
(Assignee)

Comment 18

5 years ago
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.
Attachment #602585 - Flags: review?(matspal)
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.
Attachment #602585 - Flags: review?(matspal) → review+
(Assignee)

Comment 20

5 years ago
(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.
(Assignee)

Comment 21

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/9fbe111ef1c3
https://hg.mozilla.org/mozilla-central/rev/9fbe111ef1c3
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla13
(Assignee)

Comment 23

5 years ago
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.
Attachment #603118 - Flags: review?(wjohnston)
Comment on attachment 603118 [details] [diff] [review]
followup

Thanks!
Attachment #603118 - Flags: review?(wjohnston) → review+
(Assignee)

Comment 25

5 years ago
Comment on attachment 603118 [details] [diff] [review]
followup

Whoops, I meant to ask for Mats review.
Attachment #603118 - Flags: review?(matspal)

Updated

5 years ago
Attachment #603118 - Flags: review?(matspal) → review+

Updated

5 years ago
Blocks: 700975

Updated

5 years ago
Blocks: 708407
(Assignee)

Comment 26

5 years ago
Followup
https://hg.mozilla.org/integration/mozilla-inbound/rev/6942914bc8c1
https://hg.mozilla.org/mozilla-central/rev/6942914bc8c1
Duplicate of this bug: 733209
(Assignee)

Updated

5 years ago
Duplicate of this bug: 747081
Blocks: 759993

Comment 30

5 years ago
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

5 years ago
>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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 32

5 years ago
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.
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → FIXED

Comment 33

5 years ago
Alright, thanks. I'll follow that other bug for updates.

Comment 34

4 years ago
I can still reproduce this bug with attachment 539784 [details].

Ubuntu 12.04.1 LTS
Firefox 16.0.2
(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

4 years ago
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

4 years ago
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?
(Assignee)

Comment 38

4 years ago
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

4 years ago
This is still happening on MAC....this is serius bug in my opinion, and one easy to fix.
(Assignee)

Comment 40

4 years ago
(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.
(Assignee)

Comment 41

4 years ago
You're probably seeing bug 829886 which will be fixed in Firefox 20.

Comment 42

4 years ago
No, I see THIS same bug discussed in here...
The FF version is 19 on the mac i'm seeing this right now.
(Assignee)

Comment 43

4 years ago
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.
You need to log in before you can comment on or make changes to this bug.