Context menus don't work in new windows opened from a _new targeted link

VERIFIED FIXED in mozilla0.9


18 years ago
3 months ago


(Reporter: adamlock, Assigned: adamlock)


Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: fix-in hand)


(1 attachment)



18 years ago
Embedding apps receive no calls to their context menu listener for new windows 
opened from a _new targetted link.

Steps to reproduce:

1. Run mfcEmbed
2. Load a page with a link such as <a href="" 
target="_new">Some link</a>.
3. Right-mouse click on new window. No menus appear!

Problem appears to be because the web progress notifications go to the original 
window, not the new one. This can be traced back to nsDocShell::LoadURI where it 
is clear that load operation uses the original docshell information for the 
progress notification callbacks because the new window doesn't exist yet.

Comment 2

18 years ago
it looks like the chrome listeners are being hooked up on the first
OnProgressChange() callback. why wouldn't they just get hooked up to the new
window when OnProgressChange() gets called for the new window?

Comment 3

18 years ago
from adam (edited a bit):
"The tooltip and context menu listeners are installed when the first web
progress notification arrives. The problem seems to be that for targetted
windows, the http channel opened for the link is set to send notifications to
the original window, not the targte window. This means no progress events arrive
in the new window and the listeners never get installed. Notice also in mfcEmbed
that the progress bar never updates either for the new window.

Clicking on another link in the new window does install them correctly.

I think it may be possible to move the call to 
nsDocShellTreeOwner::AddChromeListeners() to somewhere other than the progress 
notification, such as into the nsWebBrowser::Create() just after the 
nsDocShellTreeOwner object is created."

"The patch puts an explicit call to register the listeners during creation of
the web browser.

Note that only fixes the missing menus problem. The original issue of web 
progress notifications don't go to the new window is still open. I suspect that 
for this to occur the new window would have to exist before the load operation 
started, something which doesn't happen at the moment."

IMO, we should figure out why the new window isn't getting progress.

Comment 4

18 years ago
requesting 0.9 targeting.
Blocks: 64833
Keywords: mozilla0.9

Comment 5

18 years ago
The reason the new window doesn't get the progress notifications is because it 
doesn't exist when loading is initiated by nsDocShell::DoURILoad. Instead, the 
old docshell passes itself as the ifreq parameter to NS_OpenURI that specifies 
the notification callbacks. 

The solution is a bit tricky but may involve opening the new window first and 
passing the docshell to that instead, or perhaps changing the way notifications 
are registered so that a new window can fix them up at a later stage after it 
has opened.

Comment 6

18 years ago
opening the new window first makes most sense to me; hard change?

Comment 7

18 years ago
I think there would be issues about opening the window beforehand. A chrome 
window has it's own progress notification needs and there won't be primary 
content docshell until it has loaded all of its chrome. We would need to wait 
for the content docshell before we could initiate our load.

I think it may be neater (and faster) if the uri loader could fix up the 
docshell to use for progress notification callbacks later on after the window 
had really been created. For example, somewhere after nsURILoader::GetTarget is 

Anyway, back to this specific bug. Jud & Rick can I have the r= & sr= on it and 
I will check-in? This alleviates the most painful symptom, although obviously 
the cause does need addressing.

Comment 8

18 years ago
making 0.9.

r=valeski. Please open a new bug new window not getting progress callbacks.
Target Milestone: --- → mozilla0.9


18 years ago
Blocks: 75664

Comment 9

18 years ago


18 years ago
Whiteboard: fix-in hand

Comment 10

18 years ago
Fix is checked in
Closed: 18 years ago
Resolution: --- → FIXED

Comment 11

18 years ago
Bug 76408 covers the more general web progress notifications issue.

Comment 12

18 years ago
Correction: Changing QA contact for the Embed API bugs to David Epstein.
QA Contact: mdunn → depstein

Comment 13

18 years ago
*** Bug 77077 has been marked as a duplicate of this bug. ***

Comment 14

18 years ago
context menus now appear after url change.


18 years ago
No longer blocks: 64833


3 months ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.