40164 - URI dispatching broken...

Status: VERIFIED FIXED

(Core :: DOM: Navigation, defect, P3)

Description

[Scott MacGregor]

If I click on a http link in mail, it loads in the current mail window instead
of getting dispatched to the browser.

Looks like something broke in the uri loader / docshell recently.

Comment 1

[Scott MacGregor]

nominating for nsbeta2.

Comment 2

[locka]

It's working for me in news articles (I haven't set up mail). Could it be a 
mail-specific thing or something that has since been fixed?

Comment 3

[Scott MacGregor]

It's actually inconsistent (and I see it for both news and mail).

Seems like sometimes we get in a mode where clicking on a url isn't propogating
the user click action through the docshell and the uri loader.

Comment 4

[lchiang]

Yes, I'm seeing this too.  5/24 win32 build. 

Comment 5

[leger]

Putting on [nsbeta2+] radar for beta2 fix. 

Comment 6

[Scott MacGregor]

*** Bug 41346 has been marked as a duplicate of this bug. ***

Comment 7

[Scott MacGregor]

Found it!! Many thanks to akkana for giving me the clue about starting with -
mail then bringing up a browser window.

The operation of creating a new browser window from the task bar is severely
broken!!! Looks like changes by jbetak to tasksOverlay.js are the culprit.

With his changes we are creating two separate browser instances when you try to
create a new browser window. And the first one causes calls like
SetWebShellWindow to be called on the original window which stomps on the
docshell  parent hierarchy chain.

I need to hack on taskOverlay.js. The goodnews is when  fix it, not only will we
fix this bug but we should make opening new browser windows much faster because
we'll be doing half the work....

Comment 8

[[e-mail] (away - not reading bugmail)]

mscott,

sorry to hear that the kludge I put into taskOverlay.js caused you all this 
trouble. I put it in, when attempting to resolve bug 27646 and it works just 
fine in the browser window. 

We are in the process of redesigning the way we propagate the charset menu 
settings, but wanted to have this fix for Beta2. It never really worked in mail 
though. I'm attaching a revamped version of tasksOverlay.js, it's closer the 
finalized state - we are not using the browser instance as our main vehicle 
anymore. Alternatively, you could also just use "window.openDialog(url, 
"_blank", "chrome,all,dialog=no", startpage);", but I'm advising against it, 
since we would like to maintain the language/encoding context for international 
users when spawning a new browser window as stated in bug 27646.

Comment 9

[[e-mail] (away - not reading bugmail)]

Attachment: Revamped tasksOverlay.js

Comment 10

[Scott MacGregor]

jbetak: that's all right. I think we can get the both of best worlds. I just
submitted a patch to your bug that should do what you want while not breaking
uri dispatching either. Plus it simplifies the JS code too. Let me know what you
think and I'll check it in.

Comment 11

[[e-mail] (away - not reading bugmail)]

mscott,

looks great - please feel free to check it in... 

Comment 12

[Scott MacGregor]

I checked in the fix to tasksOverlay.js

Comment 13

[Scott MacGregor]

*** Bug 42225 has been marked as a duplicate of this bug. ***

Comment 14

[lchiang]

*** Bug 42583 has been marked as a duplicate of this bug. ***

Comment 15

[leger]

Adding verifyme keyword.

Comment 16

[leger]

Just tested these steps with Win32 2000-07-18-11 build.  Works fine.  I get a 
browser window. Marking Verfified.