Closed Bug 562981 Opened 10 years ago Closed 10 years ago

Mouse click event in iframe has wrong coordinates

Categories

(Firefox for Android Graveyard :: General, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: frfxtst, Assigned: vingtetun)

Details

Attachments

(3 files, 2 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.3) 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.
Attached file Testcase
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
Attached patch wip (obsolete) — Splinter Review
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?
Attached patch wip (obsolete) — Splinter Review
(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
OS: Windows 7 → All
Hardware: x86 → All
Attached patch PatchSplinter Review
Patch + tests
Attachment #443070 - Attachment is obsolete: true
Attachment #443072 - Flags: review?(mark.finkle)
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.