106445 - Clicking on URL in message pane no longer focuses browser window

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect, P2)

Description

[Leston Buell]

Regression in mail behavior. It used to be that when you clicked on a URL inside
a mail message that the targeted browser window would raise to the top.

Reproducible always:

1. Open Mozilla with both a browser window and mail open.
2. In the mail message, display a message with a URL in it.
3. Click on the URL.

Expected result:
   The existing browser window raises and the URL page is displayed.

Actual result:
   The page loads, but you have to raise the browser window manually.

Using Linux trunk build 2001-10-23-08. This bug was introduced recently. I'm not
seeing it in a 2001-10-12-08 build.

Comment 1

[R.K.Aa.]

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

Comment 2

[R.K.Aa.]

also seen on 10/24 trunk build on Windows 2000

Comment 3

[R.K.Aa.]

importing kw and priority from dup

Comment 4

[scottputterman]

reassigning to mscott.  cc'ing danm as well.

Comment 5

[Ben Ruppel]

Confirming.  Looks like just one of several regressions I've seen today.

Comment 6

[R.K.Aa.]

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

Comment 7

[R.K.Aa.]

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

Comment 8

[Håkan Waara]

This is most likely some odd focus bug in docshell...

CC focus victims: saari, bryner and adamlock.

Comment 9

[Thomas Swan]

In win32 nightly build 2001102708.  If a browser window is open, clicking a URL
in the mailnews viewer no longer loads a URL in the existing browser window.  
However, I do get the "Loading" message in the status bar for a few seconds and
the a "Done" message.

Right clicking and selecting open in new window works fine...

Comment 10

[Håkan Waara]

Thomas, that's related but not the same.  Can you file a critical bug and CC me?
 Thanks.

Comment 11

[[e-mail] (gone - use [e-mail] instead)]

updating summary to specify focus and browser window.

Comment 12

[Scott MacGregor]

hmm bryner checked in some focus related changes to Docshell the night before
this problem showed up. He was making changes for tabbed browsing. That looks
like a good place to start. Looks like some changes were made as to when a
docshell gets focus. 

btw, this bug isn't mailnews specific, I've been browsing on a page and clicked
on a link where content loads in another open browser and that window doesn't
get focus either. 

Comment 13

[Brian Ryner (not reading)]

mscott, just to clarify, I was making changes for tab navigation (i.e. with the
tab key), not tabbed browsing.  I suspect this could have started happening if
someone is focusing the docshell instead of focusing the domwindow.  I'm not
sure where this all happens at.

Comment 14

[Scott MacGregor]

oops sorry bryner. Do you want me to find a different owner for the bug? 

I can say that I had originally hooked this up back in the 6.0 days (looks like
the code is still there) to work in nsDSURIContentListener::DoContent. If a
browser receives redirected content, it takes focus by calling:
    if(loadFlags & nsIChannel::LOAD_RETARGETED_DOCUMENT_URI)
        mDocShell->SetFocus();

maybe we aren't getting the retargeted document uri load flag anymore. Or mabye
the implementation of SetFocus isn't working anymore.

This code hasn't changed for a long time though. 

Comment 15

[R.K.Aa.]

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

Comment 16

[Alfonso Martinez]

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

Comment 17

[R.K.Aa.]

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

Comment 18

[Brian Ryner (not reading)]

not going to make it for 0.9.6, sorry.

Comment 19

[selmer (gone)]

This is a serious usability issue.  Adding nscatfood keyword.

Comment 20

[Dan M]

Just a note: we do understand what's happening here. At the time the browser
window is focused its content has already been torn down preparatory to loading
the new page. nsDocShell::SetFocus once knew how to deal with those conditions,
but focus was recently given a major spanking and that bit fell through the
cracks. Brian is on it.

Comment 21

[Brian Ryner (not reading)]

Attachment: patch

This patch tries to focus the domwindow from nsDocShell::SetFocus.

Comment 22

[saari (gone)]

looks innocent enough (ha!) I can give it a try on macos.
Make sure hyatt sees it too

Comment 23

[Dan M]

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

Comment 24

[Dan M]

The patch is pretty much a re-enactment of the last patch to fix this problem,
version 1.311. That patch had a long and healthy life. The difference being that
1.311 only did this if other normal attempts to focus content within the
docshell had already failed. This version tries it right up front. But the whole
method is already quite different. If Brian has accounted for that difference,
this would seem the right thing (tm).

Comment 25

[Judson Valeski]

also note that the URL bar does not reflect the newly loaded URL; separate bug?

Comment 26

[Scott MacGregor]

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

Comment 27

[Brian Ryner (not reading)]

er, yeah, that would be a separate bug.  danm, this method is no longer
responsible for focusing any content inside the docshell, so this is all we need
to do.  saari, have you had a chance to test this on mac yet?

Comment 28

[Brian Ryner (not reading)]

Attachment: patch v2

Ok, this patch just focuses the docshell's domwindow instead of calling
SetFocus on the docshell.  The effects of this are better understood, and per
discussion with saari we may want to get rid of focus-related API's on docshell
altogether.

Comment 29

[Johnny Stenback (:jst)]

Comment on attachment 58626 [details] [diff] [review]
patch v2

r=jst

Comment 30

[David Hyatt]

sr=hyatt

Comment 31

[Brian Ryner (not reading)]

checked in

Comment 32

[Francisco León]

Verified on linux cvs, works fine

Comment 33

[Olga]

Verified on Win2K, Linux, and Mac OSX on today's and previous builds.

Comment 34

[Boris Zbarsky [:bzbarsky]]

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