Closed Bug 106445 Opened 23 years ago Closed 23 years ago

Clicking on URL in message pane no longer focuses browser window

Categories

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

Product:
SeaMonkey
Component:
MailNews: Message Display
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.7

People

(Reporter: bulbul, Assigned: bryner)

References

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

patch v2
(deleted), patch
jst
: review+
Details | Diff | Splinter Review 
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.
*** Bug 106458 has been marked as a duplicate of this bug. ***
also seen on 10/24 trunk build on Windows 2000
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
OS: Linux → All
importing kw and priority from dup
Keywords: nsbeta1
Priority: -- → P2
reassigning to mscott.  cc'ing danm as well.
Assignee: sspitzer → mscott
Target Milestone: --- → mozilla0.9.6
Confirming.  Looks like just one of several regressions I've seen today.
*** Bug 106898 has been marked as a duplicate of this bug. ***
*** Bug 106984 has been marked as a duplicate of this bug. ***
This is most likely some odd focus bug in docshell...

CC focus victims: saari, bryner and adamlock.
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...




Thomas, that's related but not the same.  Can you file a critical bug and CC me?
 Thanks.
Keywords: nsbeta1 → nsbeta1+
updating summary to specify focus and browser window.
Hardware: PC → All
Summary: clicking on URL in message pane no longer raises targeted window → Clicking on URL in message pane no longer focuses browser window
Blocks: 104864
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.
Assignee: mscott → bryner
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.

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. 
*** Bug 108119 has been marked as a duplicate of this bug. ***
No longer blocks: 104864
*** Bug 107936 has been marked as a duplicate of this bug. ***
Blocks: 104864
*** Bug 108260 has been marked as a duplicate of this bug. ***
not going to make it for 0.9.6, sorry.
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.6 → mozilla0.9.7
QA Contact: esther → olgam
This is a serious usability issue.  Adding nscatfood keyword.
Keywords: nsCatFood
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.
Attached patch patch (obsolete) (deleted) — — Splinter Review 
This patch tries to focus the domwindow from nsDocShell::SetFocus.
looks innocent enough (ha!) I can give it a try on macos.
Make sure hyatt sees it too
*** Bug 110314 has been marked as a duplicate of this bug. ***
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).
also note that the URL bar does not reflect the newly loaded URL; separate bug?
*** Bug 110352 has been marked as a duplicate of this bug. ***
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?
Attached patch patch v2 (deleted) — — Splinter Review 
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.
Attachment #57104 - Attachment is obsolete: true
Comment on attachment 58626 [details] [diff] [review]
patch v2

r=jst
Attachment #58626 - Flags: review+
sr=hyatt

checked in
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Verified on linux cvs, works fine
Verified on Win2K, Linux, and Mac OSX on today's and previous builds.
Status: RESOLVED → VERIFIED
*** Bug 113705 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: