Closed
Bug 46848
Opened 24 years ago
Closed 24 years ago
nsIWebBrowser needs to be root of all embedding listener registration
Categories
(Core Graveyard :: Embedding: APIs, defect, P1)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9
People
(Reporter: jud, Assigned: jud)
References
Details
(Keywords: embed, Whiteboard: [nsbeta3-])
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
addWebBrowserListener should be the common listener registration location.
nsIWebProgressListener, nsIURIContentListener, etc.
Assignee | ||
Updated•24 years ago
|
Whiteboard: [nsbeta3+]
Assignee | ||
Updated•24 years ago
|
Target Milestone: --- → M18
Assignee | ||
Updated•24 years ago
|
Priority: P3 → P1
per email with Jud, changing nsbeta3+ to nsbeta3- on all "embed" keyword bugs
since embedding changes will not be made in the mn6 branch. If you feel this bug
fix needs to go into mn6 branch, please list the reasons/user impact/risk and
nominate for rtm. Thanks.
Whiteboard: [nsbeta3+] → [nsbeta3-]
Assignee | ||
Updated•24 years ago
|
Target Milestone: M18 → mozilla0.6
Assignee | ||
Updated•24 years ago
|
Target Milestone: mozilla0.6 → mozilla0.8
Assignee | ||
Comment 3•24 years ago
|
||
I've pulled out the old, unused registration impl, and added the new one (as
discussed in npm.embedding -> "nsIWebBrowser" in the subject). nsWebBrowser no
longer supports nsIWebProgress. My only concern here is that people are using
nsWebBrowser's GetDOMWindow() method (which is part of nsIWebProgress). I see
two potential use problems.
1. nsWebBrowser, as a nsIWebProgress, is being passed around in
nsIWebProgressListener callbacks. Those callbacks then use GetDOMWindow().
2. People are QI'ing nsWebBrowser for nsIWebProgress and directly using
GetDOMWindow().
I think #2 is easy to fix, as you can get a nsIDOMWindow off of nsIWebBrowser
itself. #1 seems hard, but is only an issue if nsWebBrowser is ever registered
as a nsIWebProgress (which it currently is not).
attatching patch.
Assignee | ||
Comment 4•24 years ago
|
||
Assignee | ||
Comment 5•24 years ago
|
||
after poking around a bit more, nsWebBrowser doesn't register itself as a
progress listener, so I suspect I'm in the clear (unless someone's using it
internally as a listener :-/); thoughts?
All the current GetDOMWindow() calls are done inside a webprogresslistener
callback for usage case #2 isn't an issue.
Comment 6•24 years ago
|
||
This patch looks great... (r=rpotts) or (sr=rpotts) - whichever you want :-)
-- rick
Assignee | ||
Comment 7•24 years ago
|
||
fix is in.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 9•24 years ago
|
||
reopening. change of direction here. the singleton listeners should still
register using the Add|Remove listener methods on nsIWebBrowser. The multi
listener semantics can be mainted by maintaining a list of registered listeners
in the nsWebBrowser impl. The nsWebBrowser would make itself a singleton
listener when necessary, and fan out the listener callbacks to multiple
listeners if necessary.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Updated•24 years ago
|
Target Milestone: mozilla0.8 → mozilla0.9
Assignee | ||
Comment 10•24 years ago
|
||
closing, again. see http://www.mozilla.org/projects/embedding/listeners.html for
usage info.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Comment 11•24 years ago
|
||
Correction: Changing QA contact for the Embed API bugs to David Epstein.
QA Contact: mdunn → depstein
Comment 12•24 years ago
|
||
nsIWebBrowser::addWebBrowserListener() is the definitive way to register
listeners. I tried other add listener methods (e.g. addProgressListener()) and
they didn't work in MFCEmbed. (I've since found out they're private methods).
Status: RESOLVED → VERIFIED
Updated•6 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•