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.

Note that this behavior is also apparent in FF 3.6, and 5b5 (have not tested on 5b7)

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.

Crud - this is possibly a duplicate of: https://bugzilla.mozilla.org/show_bug.cgi?id=599938 Apologies - I didn't find this before.

(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 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

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?

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

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!

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!

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.

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.

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 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.

(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.

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 on attachment 603118 [details] [diff] [review] followup Thanks!

Comment on attachment 603118 [details] [diff] [review] followup Whoops, I meant to ask for Mats review.

Followup https://hg.mozilla.org/integration/mozilla-inbound/rev/6942914bc8c1

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.

>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

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.

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

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

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).

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?

Like Peter said the remaining issues here are covered by bug 759993. It is highly unlikely any Firefox 16 release would fix these issues.

This is still happening on MAC....this is serius bug in my opinion, and one easy to fix.

(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.

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

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

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.