Open
Bug 282266
Opened 19 years ago
Updated 2 years ago
<input type="image"> with DOM-dispatched click event does not compute x, y coordinates
Categories
(Core :: DOM: Events, defect, P5)
Tracking
()
NEW
People
(Reporter: WeirdAl, Unassigned)
Details
(Keywords: dom2, good-first-bug, testcase)
Attachments
(3 files, 1 obsolete file)
3.06 KB,
image/png
|
Details | |
1.17 KB,
text/html
|
Details | |
3.11 KB,
patch
|
bzbarsky
:
review-
jst
:
superreview+
|
Details | Diff | Splinter Review |
If you manually click on an <input type="image"> element, Mozilla submits the (x,y) coordinates, relative to the image's upper left corner, of where you clicked. However, if a DOM HTML click event is dispatched to the same element to the same screen coordinates, the submitted (x,y) pair is (0,0). Testcase coming up in a few minutes.
Reporter | ||
Comment 1•19 years ago
|
||
Reporter | ||
Comment 2•19 years ago
|
||
Steps to reproduce: (1) Open the testcase. (2) Click on the red box. (3) Hixie's echo test tool will appear. Note the values at the very end of the page (approximately test.x=417&test.y=35). (4) Go back to the testcase. (5) Click on the button. (6) Examine the echo test tool results again. Expected results: test.x and test.y have specific values which are non-zero at the end of Hixie's echo tool. Actual results: test.x=0&test.y=0 at the end of Hixie's echo tool.
Reporter | ||
Comment 3•19 years ago
|
||
Here's what I think is happening: nsHTMLFormElement.cpp#1062 <form> tells <input type="image"/> to report its controls. nsHTMLInputElement.cpp#2179 <input type="image"/> looks up its X and Y coordinates from the image control frame. nsImageControlFrame.cpp#375 This looks up the X coordinate from an internal value, mLastClickPoint.x. Now, here's the catch: nsImageControlFrame.cpp#140 The coordinates are initialized to (0,0)... nsImageControlFrame.cpp#263 This line would have reset the coordinate appropriately, if the event was a mouseup (line 259). Since it's not, the click forces a submit of coordinates (0,0). Am I close? Suggestions?
Reporter | ||
Comment 4•19 years ago
|
||
Added an extra test per timeless: we don't want to change the coordinates sent by calling HTMLInputElement.click().
Attachment #174331 -
Attachment is obsolete: true
Comment 5•19 years ago
|
||
seems like using the click event instead of the mouseup event makes sense.
Reporter | ||
Comment 6•19 years ago
|
||
Something rather interesting: it doesn't matter if you forcibly dispatch a click event or a mouseup event. We never compute the coordinates.
Reporter | ||
Comment 7•19 years ago
|
||
This patch checks in nsHTMLInputElement to see if aDOMEvent is non-null. I'm not sure this is the right way to go (I'd prefer checking a property of aEvent, instead). Also, timeless has raised an issue for me to test with regard to image maps. I don't quite see how that could affect anything, but I will test.
Assignee: events → ajvincent
Status: NEW → ASSIGNED
Reporter | ||
Comment 8•19 years ago
|
||
bz gave a sr- over irc, with two testcases. Basically, custom positioning changes the view that this code relies on.
Reporter | ||
Updated•19 years ago
|
Assignee: ajvincent → events
Status: ASSIGNED → NEW
jst: we'd like to get this into cvs, as is (with iid bumping as necessary), or ifdef CENZIC if absolutely necessary. bz would prefer not ifdef'ing CENZIC.
Comment 10•19 years ago
|
||
Comment on attachment 174736 [details] [diff] [review] patch, draft 1 this code is from Cenzic Hailstorm 2.5-2.6
Attachment #174736 -
Flags: superreview?(jst)
Attachment #174736 -
Flags: review?(jst)
Comment 11•19 years ago
|
||
Er.. I'd prefer not ifdefing CENZIC for patches which are sort of correct. This change is not. How about fixing this so that it uses client or screen throughout? That is, pass in the DOM event, get its screen coords, get the frame's screen coords, etc. That might work right in the cases this patch originally failed in...
Comment 12•19 years ago
|
||
Comment on attachment 174736 [details] [diff] [review] patch, draft 1 Rev the IID in nsIImageControlFrame. r+sr=jst
Attachment #174736 -
Flags: superreview?(jst)
Attachment #174736 -
Flags: superreview+
Attachment #174736 -
Flags: review?(jst)
Attachment #174736 -
Flags: review+
Comment 13•19 years ago
|
||
Comment on attachment 174736 [details] [diff] [review] patch, draft 1 I'm actually going to mark this r- per comment 11. Sending wrong data is worse than sending no data at all.
Attachment #174736 -
Flags: review+ → review-
Comment 14•19 years ago
|
||
Some additional comments: As mentioned, when submitting a form via an image input element, the POST string will be appended with 0,0 coords for the clicked input image element ...&MyImageName.x=0&MyImageName.y=0 Instead of appending the proper offset coords: ...&MyImageName.x=7&MyImageName.y=9 What may not be immediately apparent is that these extra post parameters let the server-side CGI scripts determine which image input element (out of a possible set on the page) was clicked. That is, the image name with non-zero x and y coords is the one that was clicked, all the others were not. I too have confirmed that there is a difference between interactive and synthetic event creation. Using an onSubmit event listener, I can see that when I click an image input element interactively, the event that is caught has an explicitOriginalTarget child node that points to the correct HTMLInputElement that I clicked on. It shows the necessary image offset coordinates which are appended to the post string. However, if I recreate the exact same event programmatically using initMouseEvent, that same onSubmit handler will show the explicitOriginalTarget as an HTMLFormElement elment instead, resulting in lost image offset data. The only possible way I can see to around this is hacking the in-flight post data stream to override the .x=0 and .y=0 values to non-zero values so the client CGI can tell which image what selected -- a nasty workaround. Is there a better alternative (workaround) that can be used in a Firefox extension that would not require all users to patch their Firefox client?
Comment 15•17 years ago
|
||
I cannot reproduce this issue with Firefox 2.0.0.8. Alex, can you try again and resolve WORKSFORME if everything works?
Reporter | ||
Comment 16•17 years ago
|
||
With Firefox 2.0.0.8 on WinXP, I get inconsistent results, depending on the order of clicks.
Comment 17•16 years ago
|
||
Confirmed that this is still and issue in FF 2.0.0.16 and FF 3.0.1 I don't see any inconsistencies in the results I get, using different sites. Here's an example of a POST that was generated after synthetically injecting mouse events (onMousedown, onMouseClick and onMouseUp): "__EVENTTARGET=&__EVENTARGUMENT=&__VIEWSTATE=.....(middle content truncated).....&btnLogon.x=0&btnLogon.y=0"
Comment 18•16 years ago
|
||
This is still an issue in FF3 (if a DOM HTML click event is dispatched the submitted (x,y) pair is (0,0) regardless of what is passed in initMouseEvent). The patch provided by Alex has rotted since the code it was playing with has very much changed. Anyone know how to fix this in the scheme of things?
Comment 19•16 years ago
|
||
I doubt that it's really changed that much, actually... should be a pretty straightforward port, in fact.
Whiteboard: [good first bug]
Updated•15 years ago
|
Assignee: events → nobody
QA Contact: ian → events
Comment 20•13 years ago
|
||
Status (three years later): reproducible in the versions that I have at hand. Mozilla/5.0 (Windows NT 5.1; rv:5.0.1) Gecko/20100101 Firefox/5.0.1 http://hg.mozilla.org/releases/mozilla-release/rev/3ded311d93ad Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20100101 Firefox/6.0 http://hg.mozilla.org/releases/mozilla-release/rev/218ed8178b1e
Updated•10 years ago
|
Whiteboard: [good first bug] → [good first bug][exterminationweek]
Comment 21•9 years ago
|
||
Assuming this is still a thing, I'm going to recirculate this to the community.
Whiteboard: [good first bug][exterminationweek] → [good first bug]
Comment 22•9 years ago
|
||
As of the latest nightly, the provided test case returns either 0, 0; or if you have already manually clicked on the image, it will instead return the last clicked coordinates. I'd be willing to work on this, but may need some additional direction as this will be my first bug.
Comment 23•9 years ago
|
||
Kenneth, I'm happy to help out as needed. Have you got a build environment set up and all that already?
Comment 24•9 years ago
|
||
I do have a build environment set up in Windows, and have been able to successfully build twice; however, it's a bit finicky, so I'm probably just going to download the build VM so I (hopefully) don't have to worry about it.
Updated•6 years ago
|
Priority: -- → P5
Updated•4 years ago
|
Keywords: good-first-bug
Whiteboard: [good first bug]
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•