Closed Bug 138237 Opened 22 years ago Closed 22 years ago

open URL in new tab has bad focus

Categories

(SeaMonkey :: Tabbed Browser, defect)

Product:
SeaMonkey
Component:
Tabbed Browser
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.0.1

People

(Reporter: panemec, Assigned: bryner)

References

Details

(Keywords: access, Whiteboard: [adt2 rtm] custrtm- [verified on trunk])

Attachments

(1 file)

patch
1.00 KB, patch
dbaron
: review+
waterson
: superreview+
asa
: approval+
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9+)
Gecko/20020410
BuildID:    2002041003

Opening a URL in a new tab does not have the correct focus.

This means that hitting PgDown (to scroll down), or Ctrl-PgDown (to switch to
the next tab) doesn't work until tab is hit.

Reproducible: Always
Steps to Reproduce:
1.  Open a page with some links
2.  Right click on the link and select "Open Link in New Tab"
3.  Hit PgDown
4.  Hit Ctrl-PgDown

Actual Results:  Nothing happens with PgDown or Ctrl-PgDown

Expected Results:  PgDown should scroll
Ctrl-PgDown should change to the first tab
confirmed on Linux too.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Seems fixed in 2002041803 trunk

hm, i encountered this while testing bug 37638 --see attachment 79912 [details] for the
tests i ran and the results. this would be covered by case (e) in that attachment.

my trunk results were based on 4/17 bits...haven't gotten to more recent trunk
ones, but i'll add this as dependent on 37638 so that i can doublecheck this bug.
Depends on: 37638
No longer depends on: 37638
Still a problem in OS/2 trunk 2002042608.
*** Bug 140445 has been marked as a duplicate of this bug. ***
Although it is mostly fixed (in 2002042408), there is still a bug.

The focus is not correct until the page is at least partially loaded...

To reproduce:

1. Open a page with links
2. open a link in a new tab
3. quickly hit Ctrl-PgDown before page is loaded (nothing happens)
4. once page is loaded Ctrl-PgDown works as expected

On the Mac OS X platform (build 2002042608), it's even more broken, still.
Opening a link in a new tab (not a new window) loses all keyboard focus.
Clicking with the mouse regains the focus, but until then *nothing* on the
keyboard works, not even when the page is fully loaded.

Noting that this bug was marked as "fixed", I entered this bad behaviour as a
new bug (figuring it to be platform-specific, as it seems to be). See my
description in bug #140445 for more details.
Depends on: 37638
Severity: normal → major
No longer depends on: 37638
Keywords: access, nsbeta1
Confirm the problem in RC2 under Win98. Strangely, 0.99 worked fine.
Broken in RC2 under XP as well :(
Where's the field for setting the annoyance level this bug causes?  I need to
max it out.
nsbeta1+/adt3 per Nav triage team
Whiteboard: [adt3]
Target Milestone: --- → mozilla1.0
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt3] → [adt2]
Whiteboard: [adt2] → [adt2 rtm]
*** Bug 146229 has been marked as a duplicate of this bug. ***
*** Bug 145452 has been marked as a duplicate of this bug. ***
I'll take this.  There seem to be some deep focus issues relating to initial
reflow of the sync-loaded about:blank document.
Assignee: jaggernaut → bryner
Whiteboard: [adt2 rtm] → [adt2 rtm] custrtm-
Status: NEW → ASSIGNED
Target Milestone: mozilla1.0 → mozilla1.0.1
Attached patch patch — — Splinter Review 
Here's a general description of the problem and how this fixes it:

When a new docshell is created, it synchronously loads about:blank.  For
background on this, see bug 104361.  When we create a new tab, we create an
iframe (which creates a corresponding docshell), and then focus it.  This
causes the domwindow to focus its widget, which then dispatches an NS_GOTFOCUS
event through the view system to the presshell.  Under normal circumstances,
the presshell would send the event on to the EventStateManager, which would
cause the event listeners for focus events to be called.  The focus controller
is one such listener, and would update its idea of the active window.

In this case, at the time the focus event happens, we have not ever reflowed
the about:blank document (in fact, this document is never reflowed, it is
simply replaced by the real document).	Since we have not reflowed, there are
no frames created, and the event dispatch code simply throws the event away if
there is no frame associated with the view that got the event.	So, we end up
with a situation where the focus controller's state is out of sync with the
actual widget focus.

Then, when painting is unsuppressed on the url being loaded into the new tab,
we ask the focus controller if the old document (about:blank) is focused.  If
if is, we focus the new document, and the old document is destroyed.  The
problem is, the focus controller is unaware that the about:blank document has
widget focus.  So, we destroy the focused widget without ever focusing
something else which (on Linux, at least) causes all key events to go dead.

This patch causes an initial reflow to happen if we get a focus event and have
not already done an initial reflow, to ensure that the focus controller gets
updated.
jst, this is the bug we talked about.  Any thoughts on my patch, or other ways
to fix this?
dbaron, waterson, any thoughts on this?
Comment on attachment 85664 [details] [diff] [review]
patch

sr=waterson
Attachment #85664 - Flags: superreview+
Comment on attachment 85664 [details] [diff] [review]
patch

r=dbaron.  If this does anything bad, we'll find out soon enough...
Attachment #85664 - Flags: review+
Comment on attachment 85664 [details] [diff] [review]
patch

a=asa (on behalf of drivers) for checkin to the 1.1 trunk.
Attachment #85664 - Flags: approval+
Checked in on the trunk.  I'll let this bake for 2-3 days before checking it in
on the branch.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
tested this out using 2002.06.10.0x commercial trunk bits (linux, win2k, mac
osx), and this looks good(*) when selecting "open link in new tab" from the
context menu.

(*) however, the catch is that bug 141295 interferes with the reliablity of
focus in a new window/tab/startup. ie, for this bug, when 141295 crops up,
keyboard navigation (scrolling) won't work after opening a url in a new tab.
Whiteboard: [adt2 rtm] custrtm- → [adt2 rtm] custrtm- [verified on trunk]
nominating for the branch.
Keywords: adt1.0.1, mozilla1.0.1
please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+"
keyword and add the "fixed1.0.1" keyword.
Keywords: mozilla1.0.1 → mozilla1.0.1+
sairuh - can you pls verify this fix on the trunk? thanks!
jaime --i already did: see comment 22 and the status whiteboard. :)
Marking verified, since that's the Thing To Do for bugs verified on the trunk.
Status: RESOLVED → VERIFIED
adt1.0.1+ per adt. please mark fixed1.0.1 when this lands in the branch.
Keywords: adt1.0.1 → adt1.0.1+
checked into the branch.
Keywords: mozilla1.0.1+ → fixed1.0.1
*** Bug 140140 has been marked as a duplicate of this bug. ***
from bug 140140:
this started happening with checkin for bug 138237.
also, the patch here did not fix loading cached or local pages in a new tab.
verified on the branch using 2002.06.27.0x comm bits (w/same caveats in comment 22).
Keywords: fixed1.0.1 → verified1.0.1
This bug and bug #140140 (the one I am concerned with but unfortunately marked
as a duplicate) are not fixed.

Steps to Reproduce: (Win XP - Firefox 0.9.3)
1. Open a page 
2. Hit ctrl+T
2. Hit ctrl+PgDown

Actual Results: autocomplete for address field is displayed
Expected Results:  display previous tab
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: