Closed
Bug 506304
Opened 15 years ago
Closed 15 years ago
Wrong context menu position and dynamic hovering with windowless flash inside iframe
Categories
(Core :: Web Painting, defect)
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
status1.9.2 | --- | beta1-fixed |
People
(Reporter: martijn.martijn, Assigned: roc)
References
()
Details
(Keywords: regression, testcase)
Attachments
(4 files, 2 obsolete files)
(deleted),
application/x-shockwave-flash
|
Details | |
(deleted),
text/html
|
Details | |
(deleted),
patch
|
bzbarsky
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
jaas
:
review+
|
Details | Diff | Splinter Review |
See upcoming testcase: Right clicking on the flash embed, should give the context menu popup on the right position Also, hovering over the flash embed, should make the blue circle red
Reporter | ||
Comment 1•15 years ago
|
||
Reporter | ||
Updated•15 years ago
|
Assignee | ||
Comment 4•15 years ago
|
||
A regression from the compositor landing, I presume?
Assignee: nobody → roc
Assignee | ||
Updated•15 years ago
|
Flags: blocking1.9.2+
Reporter | ||
Comment 5•15 years ago
|
||
Yes, that's what I was thinking, hence the blocking bug 352093, although, I haven't looked for the regression range.
Assignee | ||
Comment 6•15 years ago
|
||
We just need to walk all the way up the view tree until we find a widget. GetNearestWidget is the easy way to do that. This code is quite dodgy in the !aWindowless case, but I don't want to clean it up more than necessary to fix this regression.
Attachment #391024 -
Flags: review?(bzbarsky)
Assignee | ||
Comment 7•15 years ago
|
||
Writing an automated test for this is quite a chore, since we have to add support for dispatching synthesized mouse events to windowless plugins on all platforms, and add API to the test plugin to retrieve mouse event coordinates, again on all platforms. Nevertheless, here it is!
Attachment #391025 -
Flags: review?(joshmoz)
Comment 8•15 years ago
|
||
Comment on attachment 391024 [details] [diff] [review] easy fix So this is really meant to be the offset from the parent widget, not from the document? In that case, makes sense.
Attachment #391024 -
Flags: review?(bzbarsky) → review+
Assignee | ||
Comment 9•15 years ago
|
||
Checked in the actual fix: http://hg.mozilla.org/mozilla-central/rev/333fb0fdfd67 but I want to leave this open for the test code.
Assignee | ||
Updated•15 years ago
|
Whiteboard: [needs review]
Attachment #391025 -
Flags: review?(joshmoz) → review+
Assignee | ||
Comment 10•15 years ago
|
||
Checked in test patch. http://hg.mozilla.org/mozilla-central/rev/22588ab14ac6
Status: NEW → RESOLVED
Closed: 15 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [needs review]
Comment 11•15 years ago
|
||
Mass change: adding fixed1.9.2 keyword (This bug was identified as a mozilla1.9.2 blocker which was fixed before the mozilla-1.9.2 repository was branched (August 13th, 2009) as per this query: http://is.gd/2ydcb - if this bug is not actually fixed on mozilla1.9.2, please remove the keyword. Apologies for the bugspam)
Keywords: fixed1.9.2
Updated•15 years ago
|
status1.9.2:
--- → beta1-fixed
Keywords: fixed1.9.2
Updated•6 years ago
|
Component: Layout: View Rendering → Layout: Web Painting
You need to log in
before you can comment on or make changes to this bug.
Description
•