Closed Bug 562981 Opened 10 years ago Closed 10 years ago
Mouse click event in iframe has wrong coordinates
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:220.127.116.11) Gecko/20100401 Firefox/3.6.3 Build Identifier: 20100430021320 - An iframe has registered "click" events via "addEventListener". - The body of the iframe src file doesn't have the height of the displayed frame rectangle. - If you click in the iframe below the body, the wrong mouse coordinates are sent. In Fennec version 1.0 this worked without problems. Please check attached example. For add-ons which want to react on the click event, this is a pretty serious problem. Reproducible: Always Steps to Reproduce: 1. Unzip the attached testcase 2. Open the file "click_test.html" in Fennec 3. Click in the lower part of the left iframe window Actual Results: Everytime the mouse coordinates 148, 26 are displayed no matter where you click. Expected Results: The correct mouse coordinates are displayed. Please check the right iframe as reference.
This sounds similar to bug we just fixed. I assume the difference is now the coordinates?
Yes, it's similar to 561733 which caused that no mouse events were fired. This works fine now, but I found this new problem with the coordinates.
This sounds similar but I don't think that is a regression. Looking at the attached screenshot the wrong coordinates are _only_ when you click outside the blue border which means when you click outside the <html> tag. In this case elementFromPoint didn't find any response and decide to target the iframe instead of the correct position. So this is a very specific case that we probably have in the code since a long time.
You are right, that this may be pretty specific, but it worked in Fennec 1.0 :). And if you have an add-on which relies on the right coordinates, it's a real problem.
(In reply to comment #5) > You are right, that this may be pretty specific, but it worked in Fennec 1.0 > :). I didn't realized it was a real regression! > And if you have an add-on which relies on the right coordinates, it's a > real problem. Obviously I want a patch for that, I just want to explain why the testcase fails and lower the priority. :) Anyway thanks a lot for all your bug reports and the details + testcases that you provide, this is a huge help for us. :)
Status: UNCONFIRMED → NEW
Ever confirmed: true
This quick and dirty patch correct the problem but introduce a new bug.
I don't know if this helps, but I have traced down the version where the problem started: last version where still everything was okay: 20100414022347 first version where the problem occured: 20100415024036
(In reply to comment #7) > This quick and dirty patch correct the problem but introduce a new bug. Okay, this means you don't apply this patch?
(In reply to comment #9) > (In reply to comment #7) > > This quick and dirty patch correct the problem but introduce a new bug. > > Okay, this means you don't apply this patch? Finally, I've not found any regression with such a patch. And I can't think of any case where we want to "redirect" the event when the element returns by ElementHelper.getClosest() is a HTMLHtmlElement. Also, this bug happen even if we're not in a iframe but in a HTML document not big enough to fill the whole height. This updated patch works fine. I'll convert the testcase into a test.
Assignee: nobody → 21
Attachment #442916 - Attachment is obsolete: true
10 years ago
OS: Windows 7 → All
Hardware: x86 → All
Patch + tests
Attachment #443072 - Flags: review?(mark.finkle) → review+
This is a regression from 1.0 pushed m-b: http://hg.mozilla.org/mobile-browser/rev/b5351d3e1d2d pushed m-1.1: http://hg.mozilla.org/releases/mobile-1.1/rev/bf138ca7651c
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.