Closed Bug 177030 Opened 22 years ago Closed 21 years ago

When loading a url in a new tab, tabbed browser keyboards shortcuts (Ctrl+W, Ctrl+PgUp, etc) do not work before loading is completed

Categories

(SeaMonkey :: Tabbed Browser, defect)

x86
All
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED WORKSFORME

People

(Reporter: enigma2, Assigned: jag+mozilla)

References

Details

User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.2a) Gecko/20020912
Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.2a) Gecko/20020912

ctrl-w used to close tabs any time, but with newer builds (including the latest)
ctrl-w will only close the tab after the url has loaded.  middle-clicking on a
tab has no problem, though.

Reproducible: Always

Steps to Reproduce:
1.load a url
2.create a new tab
3.load another url that takes a few seconds, and try to use ctrl-w

Actual Results:  
tab wont close until url has completely loaded

Expected Results:  
tab closes right away like in the first 1.2 (and prior) builds

p.s. the old mozilla build I'm using now works ok with ctrl-w, so ignore the
build identifier above.  I use ctrl-w a lot so newer mozilla builds are useless
to me.
Confirming moz 2002103110 win98

When you loads a url in a new tab either via context menu or middle
click, no tabbed browser keyboard shortcuts will work (Ctrl+W, Ctrl+Tab,
etc.) Other keyboard shortcuts like Ctrl+O work as expected.

The bug does no appear if you create a new tab and then load a url in it
Status: UNCONFIRMED → NEW
Component: Browser-General → Tabbed Browser
Ever confirmed: true
OS: other → All
Hardware: All → PC
Summary: ctrl-w only closes tab after page has loaded → When loading a url in a new tab, tabbed browser keyboards shortcuts (Ctrl+W, Ctrl+PgUp, etc) do not work before loading is completed
*** Bug 183130 has been marked as a duplicate of this bug. ***
I don't think it has been mentioned, but CTRL+T sometimes doesn't work while a
tab is loading either. I think this only applies to the data transfer stage, not
the rendering stage. I'm using Moz 1.2 final.
A different method to reproduce:

* load a url one one tab, load another url in another tab
* start loading a slow link
* hit Ctrl-PgDn (while loading)

What happens:
* nothing

What should happen:
* switch to other tab

Once the page is loaded then Ctrl-PgDn works fine
Failure to interact while a page is loading sounds like bug 76495.  Is this
really specific to tabs?
No, this bug is almost certainly a duplicate of bug 76495 and should be marked
as such.
for the sack of sanity, set this bug to depend on bug 76495 so that people can
find this bug.
Depends on: zombie
bug 76495 was created in 2001, yet this bug started happening around ~9/2002,
hmm... 
If the url that is loaded does not exist, the Tab can not be closed using Ctr+W.
An empty Tab page remains, until you use File > Close Tab from the menu.
*** Bug 208242 has been marked as a duplicate of this bug. ***
what's the diff between this bug and bug 110718?
I'm pretty sure this is a dup with bug 192729, which has a patch and
superreview+ (I can't wait...!). Just like that bug, clicking in the loading tab
to focus it reenables keyboard shortcuts.


->default contacts
Assignee: asa → jag
QA Contact: asa → pmac
Erm, bug 205179 looks like a dup of this one. 
By the way, this seems to be more or less fixed for me since 1.5something. If
the tab is empty, Ctrl-PgDn/PgUp has to be hit *twice* to move (in rapid
succession, sometimes once will do).

Time to look at bugs I've opened again and mark the ones I see fixed....
*** Bug 205179 has been marked as a duplicate of this bug. ***
*** Bug 230907 has been marked as a duplicate of this bug. ***
WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040125 with
Ctrl+W and Ctrl+Tab.

There's a Firebird-specific problem with Ctrl+Tab (but not other shortcuts): bug
227887.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
I think this bug was fixed by the patch in bug 192729.
Status: RESOLVED → VERIFIED
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.