keyboard freeze opening invalid URL in new tab

RESOLVED FIXED in Firefox1.5

Status

()

Firefox
Keyboard Navigation
RESOLVED FIXED
14 years ago
13 years ago

People

(Reporter: Ori Avtalion (salty-horse), Assigned: Aaron Leventhal)

Tracking

(Blocks: 1 bug, {regression})

unspecified
Firefox1.5
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050120 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050120 Firefox/1.0+

When opening an invalid URL in a new tab (by middle-clicking, or right-clicking
and choosing the "open in new tab" option), focusing on the tab ignores any
keyboard input. The mouse still works.

Reproducible: Always

Steps to Reproduce:
1. Open the URL in a new tab by middle-clicking on it: http://dslkfjweiurei.abc
2. The "URL could not be found" message pops up.
3. Press the newly-opened tab.
Actual Results:  
Try to use the keyboard: CTRL+TAB, ALT+D, F6, CTRL+W .. no response.

Expected Results:  
The browser should respond to keyboard shortcuts.
(Reporter)

Comment 1

14 years ago
This is a regression. The bug does not appear in Firefox 1.0
(Assignee)

Comment 2

14 years ago
Did it regress from the checkin of bug 249136?
Does it make a difference if you open new tabs in the background or foreground?
(Reporter)

Comment 3

14 years ago
(In reply to comment #2)
I just noticed that when opening tabs in the foreground, even valid ones, until
they ARE validated, the keyboard freezes.

Comment 5

14 years ago
Confirmed in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b)
Gecko/20050121 Firefox/1.0+

Partial workaround: Use browser.xul.error_pages.enabled.  This workaround is
partial because it only helps once Firefox realizes the page won't load.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-aviary1.1?
Keywords: regression
Blocks: 204402
OS: Windows XP → All
Hardware: PC → All
(Assignee)

Comment 6

14 years ago
I'm sure this is from bug 249136. Shall I back that out?

Comment 7

14 years ago
(In reply to comment #6)
> I'm sure this is from bug 249136. Shall I back that out?

Would be nice if there isn't a fix in sight for this bug here.

Comment 8

14 years ago
*** Bug 281159 has been marked as a duplicate of this bug. ***

Comment 9

14 years ago
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b) Gecko/20050205
Firefox/1.0+

I came here from Bug 281159 . The manifestation on the Mac is (at least usually)
that such 'empty' Tabs close on the second application of Cmd-W or using the Close
Tab menu item with the mouse. 

The latter is sufficient work around, so this is a low priority bug.

(I can't actually remember a time when this defect was not in).
(In reply to comment #9)
> (I can't actually remember a time when this defect was not in).

I guessed you suffered from this regression here, since with Mozilla 1.7.5 for
example closing tabs with ctrl+w worked (but this a current trunk build it doesn't).
(Assignee)

Comment 11

14 years ago
I think focus is probably somehow going to the DOM window itself.
(Assignee)

Comment 12

14 years ago
Strike that, I forgot it's bug 249136. I'll back that out today and we'll look
for a new fix to bug 249136.
(Assignee)

Comment 13

14 years ago
Fix for bug 249136 backed out.
Reopen if you still see a problem.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
Flags: blocking-aviary1.1?
Target Milestone: --- → Firefox1.1
You need to log in before you can comment on or make changes to this bug.