Closed
Bug 671160
Opened 13 years ago
Closed 13 years ago
ASSERTION: Uh, inner window set as event target!
Categories
(Toolkit :: Password Manager, defect, P1)
Tracking
()
VERIFIED
FIXED
mozilla8
| Tracking | Status | |
|---|---|---|
| firefox5 | --- | unaffected |
| firefox6 | --- | unaffected |
| firefox7 | --- | unaffected |
| firefox8 | + | fixed |
| firefox9 | + | fixed |
| firefox10 | + | fixed |
| status1.9.2 | --- | unaffected |
| status1.9.1 | --- | unaffected |
People
(Reporter: MatsPalmgren_bugz, Assigned: bzbarsky)
References
Details
(Keywords: assertion, regression, Whiteboard: [sg:high][qa-])
Attachments
(2 files)
|
(deleted),
text/plain
|
Details | |
|
(deleted),
patch
|
smaug
:
review+
|
Details | Diff | Splinter Review |
STEPS TO REPRODUCE
1. run mochitest toolkit/components/passwordmgr/test/test_master_password.html
ACTUAL RESULTS
###!!! ASSERTION: Uh, inner window set as event target!: '!win || !win->IsInnerWindow()', file content/events/src/nsDOMEvent.cpp, line 878
PLATFORMS AND BUILDS TESTED
Bug occurs in a local mozilla-central DEBUG build on Linux x86-64
|
||
Comment 1•13 years ago
|
||
Can't reproduce. Can you get the stack?
|
Reporter | |
Comment 2•13 years ago
|
||
|
|
||
Comment 3•13 years ago
|
||
Bz, probably a regression from nsGlobalWindow::DispatchCustomEvent change.
We should dispatch the event to outer window.
Sorry, I should have noticed the problem when reviewing.
We could either just fix this bug, or make
event dispatching to handle this case.
I think I prefer the first option, since that forces caller to think about
whether to use inner or outer window.
Assignee: nobody → bzbarsky
|
Assignee | |
Comment 4•13 years ago
|
||
Attachment #545692 -
Flags: review?(Olli.Pettay)
|
|
Assignee | |
Updated•13 years ago
|
Priority: -- → P1
Whiteboard: [need review]
|
|
||
Updated•13 years ago
|
Attachment #545692 -
Flags: review?(Olli.Pettay) → review+
|
|
Assignee | |
Updated•13 years ago
|
Whiteboard: [need review] → [need landing]
|
||
Updated•13 years ago
|
status1.9.1:
--- → unaffected
status1.9.2:
--- → unaffected
status-firefox5:
--- → unaffected
status-firefox6:
--- → unaffected
status-firefox7:
--- → unaffected
status-firefox8:
--- → affected
Keywords: regression
Whiteboard: [need landing] → [sg:high]
|
|
Assignee | |
Comment 5•13 years ago
|
||
Daniel, please don't nuke my status whiteboard annotations? I actually use them to track what I need to do...
Whiteboard: [sg:high] → [sg:high][need landing]
|
|
Assignee | |
Comment 8•13 years ago
|
||
Flags: in-testsuite?
Whiteboard: [sg:high][need landing] → [sg:high]
Target Milestone: --- → mozilla8
|
||
Comment 9•13 years ago
|
||
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
|
||
Updated•13 years ago
|
status-firefox10:
--- → fixed
status-firefox9:
--- → fixed
tracking-firefox10:
--- → +
tracking-firefox8:
--- → +
tracking-firefox9:
--- → +
|
||
Comment 10•13 years ago
|
||
Is there something QA can do to verify this fix? If not, could you verify the fix Mats?
Whiteboard: [sg:high] → [sg:high][qa?]
|
|
Reporter | |
Comment 11•13 years ago
|
||
The test pass with no assertions in my local debug build on Linux64.
Backing out the fix brings it back.
Status: RESOLVED → VERIFIED
|
|
||
Updated•13 years ago
|
Group: core-security
You need to log in
before you can comment on or make changes to this bug.
Description
•