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)

x86
Windows 98
defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9

People

(Reporter: jud, Assigned: jud)

References

Details

(Keywords: embed, Whiteboard: [nsbeta3-])

Attachments

(1 file)

addWebBrowserListener should be the common listener registration location. nsIWebProgressListener, nsIURIContentListener, etc.
Keywords: embed
Keywords: nsbeta3
Whiteboard: [nsbeta3+]
Target Milestone: --- → M18
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-]
Target Milestone: M18 → mozilla0.6
Target Milestone: mozilla0.6 → mozilla0.8
Updating QA Contact
QA Contact: jrgm → mdunn
Blocks: 64833
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.
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.
This patch looks great... (r=rpotts) or (sr=rpotts) - whichever you want :-) -- rick
fix is in.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Verified fixed -- source changed
Status: RESOLVED → VERIFIED
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 → ---
Target Milestone: mozilla0.8 → mozilla0.9
Blocks: 70229
Status: REOPENED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
Correction: Changing QA contact for the Embed API bugs to David Epstein.
QA Contact: mdunn → depstein
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
No longer blocks: 64833
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: