Closed Bug 290177 Opened 18 years ago Closed 15 years ago

ctrl + pgdown / pgup not switching tab when caret in one-line textbox

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P3)

defect

Tracking

()

RESOLVED FIXED

People

(Reporter: nirvn.asia, Assigned: neil)

References

Details

(Keywords: access, regression)

Attachments

(1 file, 2 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050413 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050413 Firefox/1.0+

two nice keyboard shortcut stopped two work in the trunk. CTRL+PGDOWN and
CTRL+PGUP used to move within the opened tabs of a window and it stopped to work
in the recent build (I'ld say not to search behond one week for possible patch
that caused this regression)

Reproducible: Always

Steps to Reproduce:
Keywords: regression
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050413
Firefox/1.0+
New profile WFM. Except when the caret was in the text box on the google-firefox
homepage, then it didn't work.
I have a feeling this might be the same kind of regression as bug 290172.
Certainly, with firefox 1.02, CTRL-PGUP and CTRL-PGDN changes tab when a
one-line textbox has focus changes tabs, but in official nightly Mozilla/5.0
(Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050413 Firefox/1.0+ this
is no longer the case.
OK sorry for all the irrelevent comments. This bug is also present in
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050411
Firefox/1.0+
so it must have regressed before that.
Component: Tabbed Browser → Form Manager
Summary: ctrl + pgdown / pgup not switching to next or previous tab → ctrl + pgdown / pgup not switching tab when caret in one-line textbox
QA Contact: tabbed-browser → form-manager
Steps to reproduce
1. Have two tabs open (eg: this one, and another one)
2. Click in the textbox "summary" so the caret is present in it
3. Press CTRL-PGUP or CTRL PG-DN

Expected: Change tab
Actual: auto-complete is popped
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050413
Firefox/1.0+

Ctrl-PgUp and Ctrl-PgDown still work here!
Assignee: bugs → aaronleventhal
Status: UNCONFIRMED → NEW
Component: Form Manager → Keyboard: Navigation
Ever confirmed: true
Product: Firefox → Core
QA Contact: form-manager → bugzilla
Version: unspecified → Trunk
Component: Keyboard: Navigation → Form Manager
Flags: blocking1.8b3?
Version: Trunk → 1.0 Branch
Component: Form Manager → Keyboard: Navigation
Version: 1.0 Branch → Trunk
Ctrl+pageup/pagedown are the keys to open the autocomplete history for a
textfield in IE as well, so that's the standard use of that key in a browser
textfield. I'm not actually sure who implemented that for Firefox, but anyway,
it's by design.

Use Ctrl+Tab and Ctrl+Shift+Tab to switch tabs, or Ctrl+digit.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
I thought it was just PGUP and PGDN that opened the auto-complete history for a
text-field. Certainly it works. With a modifier like CTRL I would expect tab
switching as is the norm throughout firefox when text-fields don't have focus.

Also, in the IE URL bar it is PGUP and PGDN that trigger the auto-complete
history; CTRL+PGUP and CTRL+PGDN do nothing.
Go to www.google.com in IE. Hit Ctrl+pagedown. History opens without selecting
an item.

Reopen this bug if you can prove that only plain PageUp/PageDown should do that,
or that Ctrl+Tab proves unusable for you.
Flags: blocking1.8b3?
*** Bug 210435 has been marked as a duplicate of this bug. ***
it is VERY annoying that CTRL + PGUP or PGDOWN doesnt' switch tabs.

It should do it. It works on Firefox 1.0.7 but not on branch.
*** Bug 315526 has been marked as a duplicate of this bug. ***
*** Bug 318901 has been marked as a duplicate of this bug. ***
*** Bug 319827 has been marked as a duplicate of this bug. ***
why is this resolved wontfix?  This is a clear regression from 1.0.7
*** Bug 325576 has been marked as a duplicate of this bug. ***
I'm also surprised that this is wontfix.  ctrl-shift-tab is a lot less convenient finger-wise than ctrl-pgup.  ctrl-pgup works almost all the time, only in one undocumented instance it now doesn't work.

The official list of Firefox keyboard shortcuts at http://www.mozilla.org/support/firefox/keyboard says that either works, which right now isn't the case.
This seems strange to me - filing another Bug report, bugzilla shows me this bug as hot within the last two weeks.  What's up with that?  Anyway, on my FF 1.5.0.2, ctrl+tab functionality works as expected: it cycles through the tabs in my FF window.  And I like it that way.  Seems like this should be updated to Resolved Fixed.  I have caret browsing turned on (F7).

As to Comment #8 ... if you mean going to the address bar, on my IE 6, the history is pulled down by alt+down arrow as it is with Ff (and I would suggest that this is the logical way to extend it to other contexts since there is already a standard).  ctrl+tab is standard Microsoft behaviour for switching tabs, working in Excel and Word going back to forever, and in dialog boxes such as those found in the control panel/Regional and Language Options.  I haven't tried IE 7 yet, but I would expect it to work there, too.
ctrl-pgup/down is a hell of a lot more convenient than ctrl-shift-tab, and you can already pop down the completion history with pgdown (funny, I thought alt-down arrow was the standard in Windows.  I guess the good thing about standards is there are so many to choose from)

Yes, lets emulate everything IE is doing, good and bad, and lets ignore how firefox/mozilla/netscape have been behaving for the last *decade*.
In addition to the previously stated convenience factor when going from right to left (less buttons to hold down), another issue is those OS's which use Ctrl-Tab for their own function, i.e. to switch virtual desktops.  This is responsible for a significant loss of productivity when I am browsing.  Also, I don't understand what the reasoning is for not fixing this.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Aaron and I have discussed this on IRC and he feels that consistency with IE is not compelling enough to warrant this inconvenience.  I disagree, but I'm reopening this bug at his request.
Yes, I'd prefer:
1) consistency across textfields within Mozilla and on the OS. Alt+up/down and F4 are the keys to open dropdowns. People know those keys, most users don't typically know about ctrl+pageup/pagedown for dropdowns.
2) Ctrl+tab is often used on Linux for "next desktop". Fixing this gives those users a different key combo, which is one of the reasons we had ctrl+pageup/down in the first place
3) And we get a fix for the super-annoying bug 318788 for free. It turns out we also do the dropdown for plain pageup/pagedown

As we fix this we should also make F4 drop down the list. Alt+down already works.
Assignee: aaronleventhal → mats.palmgren
Status: REOPENED → NEW
Blocks: 348235
*** Bug 350817 has been marked as a duplicate of this bug. ***
Keywords: access
*** Bug 364566 has been marked as a duplicate of this bug. ***
ctrl+tab switches virtual desktops as stated before.
many users want ctrl+pgup/pgdown to switch between tabs.

The best solution would be to do 2 things:

Make ctrl+page_up/down default-behaviour to switch between tabs.

Give possibilities to organise shortcuts for all functions in firefox.
This bug also happens on my Ubuntu Linux PC [Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.8.1.2) Gecko/20060601 Firefox/2.0.0.2 (Ubuntu-edgy)].  So, you may want to change the OS field of this bug to All.
OS: Windows XP → All
Hardware: PC → All
Duplicate of this bug: 377574
Duplicate of this bug: 307762
Attached patch Fix via tabbox capturing (obsolete) — Splinter Review
There seem to be at least three approaches to this bug. This is the first.
Assignee: mats.palmgren → neil
Status: NEW → ASSIGNED
Attachment #283704 - Flags: review?(enndeakin)
Attached patch Fix via not stopping propagation (obsolete) — Splinter Review
Alternatively we can allow the event to propagate so that tabbox.xml sees it.

The third option is not to process keys if the accelerator modifier is down.
That's likely to be a bigger patch, so I won't write it if one of these gets r+ ;-)
Attachment #283705 - Flags: review?(enndeakin)
I do think option 3 is more correct, as the autocomplete should be ignoring modified keys is shouldn't be handling, or should at least not call stopPropagation in that case. I do prefer option 2 over option 1 though.


Duplicate of this bug: 404792
Ping?

This hit me with SeaMonkey 2.0a1pre on Linux. Ctrl-Shift-Tab is so awkward I would be too ashamed to propose it to anyone and I can simply press down any arrow key to drop-down the text field (so no need to grab Ctrl-PgUp for that purpose, really).

Also, at least with SeaMonkey, pressing the arrows while being focused on the location bar makes it drop down, but Ctrl-PgUp switches tabs. I see the location bar as just an example of text entry, so this behavior is inconsistent.
Attachment #283704 - Flags: review?(enndeakin)
Comment on attachment 283705 [details] [diff] [review]
Fix via not stopping propagation

Clear review requests based on my previous comments.
Attachment #283705 - Flags: review?(enndeakin)
Attached patch Proposed patchSplinter Review
The two location bar autocomplete implementations differ in their choice of modifiers to ignore so I played safe and ignored all three.
Attachment #283704 - Attachment is obsolete: true
Attachment #283705 - Attachment is obsolete: true
Attachment #293330 - Flags: review?(enndeakin)
Attachment #293330 - Flags: review?(enndeakin) → review+
Attachment #293330 - Flags: approval1.9?
Flags: blocking1.9?
Attachment #293330 - Flags: approval1.9? → approval1.9+
+'ing and marking as P3.
Flags: blocking1.9? → blocking1.9+
Priority: -- → P3
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago15 years ago
Resolution: --- → FIXED
Duplicate of this bug: 344966
Duplicate of this bug: 360693
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.