Closed
Bug 566388
Opened 15 years ago
Closed 15 years ago
[e10s] Not all nsIWebProgress events are being delivered within the content process
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 567831
People
(Reporter: mayhemer, Assigned: jduell.mcbugs)
References
Details
On content process doing nsIDOMDocument->GetContainer()->QI(nsIWebProgress)->AddProgressListener(listener, nsIWebProgress::NOTIFY_STATE_DOCUMENT) doesn't trigger OnStateChange with nsIWebProgressListener::STATE_STOP state on the 'listener'.
This hasn't been fixed with bug 561692 (what probably has not been intention of).
|
Assignee | |
Comment 1•15 years ago
|
||
So we appear to be having a problem with nsIWebProgress events not all getting delivered in the *content* process (which makes this bug separate from bug 514705, which is about also notifying chrome via IPDL).
mfinkle is reporting he's seeing fennec only getting STATE_IS_REQUEST notifications for web content, while about: pages get all notifications.
We need to look at how the web progress events are generated, and why it's not happening under e10s. Perhaps necko ProgressEventListeners aren't working as we expect? (we should have provided them in bug 561692).
Summary: [e10s] Missing NOTIFY_STATE_DOCUMENT functionality on the content process → [e10s] Not all nsIWebProgress events are being delivered within the content process
|
|
Assignee | |
Updated•15 years ago
|
Assignee: nobody → jduell.mcbugs
|
|
Assignee | |
Comment 2•15 years ago
|
||
fixed by dougt's patch for bug 567831
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
|
||
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•