Closed Bug 200950 Opened 21 years ago Closed 15 years ago

Content area sometimes loses focus after "Open Link in New Tab" operation

Categories

(SeaMonkey :: Tabbed Browser, defect)

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

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: eijkhout, Unassigned)

References

(
URL
)

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4b) Gecko/20030406
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4b) Gecko/20030406

In some cases (theregister.co.uk often does it) opening a link in a new tab, 
and hitting space, makes the cursor disappear; the page does not go page down, 
and sometimes the page in the new tab does in fact go a page down. This bug has
been present since 1.1 as far as I can tell.

Reproducible: Sometimes

Steps to Reproduce:
1.Use contextual menu to "open link in new tab"
2.Wait until tab is loaded (?)
3.Hit space

Actual Results:  
The cursor disappears.

Expected Results:  
Scroll down one page. Btw, you do get the page down on the current page after
hitting the mouse (in my case actually the trackpad). It's like Mozilla is
looking at the wrong tab, and you have to tell it explicitly where it is.
Seems to WorkForMe using FizzillaMach/2003040103. I tried putting focus in
different places on the source page before "Open Link in New Tab," but it still
worked every time.

Victor, can you reproduce this problem using another Mozilla user profile?
Summary: After "open link in new tab" hitting space does not produce page scrool → After "Open Link in New Tab" operation, pressing space sometimes does not scroll page
Done. Still yesterday's build: Gecko/20030406. Created a completely new profile.

Select "load links in background" in "tabbed browsing" preferences. (I didn't mention that in myoriginal report; didn't realise that it was a setting.) Use "theregister.co.uk", "open link in new tab". Hit space, and the cursor disappears; nothing happens in the way of scrolling.

This is on OS X 10.2.4.


Victor.
Ah, so you're trying to scroll the *source* page, and it doesn't work. Can you
reproduce this such as space successfully scrolls a page, you "Open Link in a
New Tab", then space *stops* scrolling that page as a result?
Apologies for not making clear about source page. Forgot that it was a setting.

Anyway. I can indeed do what you're asking.

Open "theregister.co.uk":
Hit space on the opening page: it goes page down.
"open link in new tab" makes new tab
Hit space: cursor disappears (which is correct), page does not go down.

If after "open link" I move the cursor to a non-link part of the page
I still don't get a page down when I hit space, but now I can tap my
trackpad (cursor does not appear) and then space does work.

In some cases (and I can not reproduce this; no idea what circumstances bring
this about) the page in the new tab actually goes page down when I hit space
on the source page.

Also unreproducible: I believe sometimes the arrow-down key similarly does not work 
after opening a new link. Can't confirm this now that I'm trying.

Victor.
Confirmed using FizzillaMach/2003040809. I was able to reproduce the problem as
described in comment 4.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: After "Open Link in New Tab" operation, pressing space sometimes does not scroll page → Content area sometimes loses focus after "Open Link in New Tab" operation
Confirming on Win2k, so -> all/all.
Bug 194194 might be the same (but this one has the better description).
OS: MacOS X → All
Hardware: Macintosh → All
Seeing this with 20030903 CVS build on Linux. Setting as major and requesting
blocking 1.5 as this might lead to submitting forms in the background (buying
stuff at Amazon as a possible result).
URL: http://theregister.co.uk/
Severity: normal → major
Flags: blocking1.5?
*** Bug 215338 has been marked as a duplicate of this bug. ***
In duplicate bug 215338, it is described that forms might play a role in this.
*** Bug 194194 has been marked as a duplicate of this bug. ***
Bug 151073 might be related.

BTW, my Tabbed Browsing settings are that every option in the corresponding
Preferences page is checked.
Flags: blocking1.5? → blocking1.5-
Reproduced in Win98, Mozilla 1.5 (Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5)
Gecko/20031007)
Ctrl + Click > New tab
Space, cursor down and page down keys does not scrolls page. Also, "Find as you
type" (using /) finds nothing.
After clicking on tabbed page background, keys works normally. Seems like
sometimes gecko window does not gets the focus.

My Mozilla loads tabs in foreground, so this options does not affect bug occurence.

Some pages and forms:
(confirmed) theregister.co.uk, new tab for any link: Mozilla does not scrolls
(forms on both pages).
www.google.com.ar, new tab for "Preferencias": Mozilla works fine (forms on both
pages)
www.gnu.org, new tab for any link: Mozilla does not scrolls (no forms). After
various tries (with small -1 or 2 screens to scroll- pages, i think), mozilla
works fine and starts working for page that failed before. Closing all open tabs
and retrying large pages restart the problem.
I see this bug with Mozilla linux build 2004103005 on
http://www.livejournal.com/community/mathematics/449875.html

Middle-click on any (thread) link to open the link in new tab in the background
steals focus from the current page.
*** Bug 266092 has been marked as a duplicate of this bug. ***
*** Bug 279862 has been marked as a duplicate of this bug. ***
Product: Core → SeaMonkey
Assignee: jag → nobody
QA Contact: pmac → tabbed-browser
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
Fixed by bug 124750, bug 265055 or bug 299677.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.