Last Comment Bug 321128 - Ctrl-Home/Ctrl-End don't move to start/end of web page
: Ctrl-Home/Ctrl-End don't move to start/end of web page
Status: RESOLVED FIXED
: fixed-seamonkey1.0, fixed-seamonkey1.1a, fixed-seamonkey1.1b, fixed1.8.0.1, fixed1.8.1, regression, relnote
Product: SeaMonkey
Classification: Client Software
Component: UI Design (show other bugs)
: Trunk
: x86 All
: -- major with 1 vote (vote)
: ---
Assigned To: Karsten Düsterloh
:
Mentors:
: 320161 320842 321330 (view as bug list)
Depends on: 105885
Blocks: 322234 323357
  Show dependency treegraph
 
Reported: 2005-12-21 10:15 PST by Karsten Düsterloh
Modified: 2008-07-31 04:22 PDT (History)
17 users (show)
csthomas: blocking‑seamonkey1.0+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
use Ctrl+Alt as modifier and remember focus (5.29 KB, patch)
2005-12-22 18:28 PST, Karsten Düsterloh
no flags Details | Diff | Splinter Review
Mac-aware version (10.77 KB, patch)
2005-12-23 13:11 PST, Karsten Düsterloh
no flags Details | Diff | Splinter Review
v3: toolkit-lookalike, with extra candy (5.84 KB, patch)
2006-01-03 18:53 PST, Karsten Düsterloh
jag-mozilla: review+
neil: superreview-
Details | Diff | Splinter Review
Mac Classic tabs without and with focus rectangle (42.48 KB, image/png)
2006-01-04 10:28 PST, Karsten Düsterloh
no flags Details
Mac Classic tabs with -moz-mac-focusring rectangle (see comment #23) (9.92 KB, image/png)
2006-01-06 15:02 PST, Karsten Düsterloh
no flags Details
Using a tab-container (2.81 KB, patch)
2006-01-07 12:39 PST, Stefan [:stefanh]
no flags Details | Diff | Splinter Review
Screentshot of attachment #207843 in action (5.78 KB, image/gif)
2006-01-07 13:02 PST, Stefan [:stefanh]
no flags Details
v4: (most) comments addressed (6.17 KB, patch)
2006-01-12 15:22 PST, Karsten Düsterloh
mnyromyr: review+
neil: superreview+
Details | Diff | Splinter Review
v4 Mac keyboard focus (11.57 KB, image/png)
2006-01-12 15:26 PST, Karsten Düsterloh
no flags Details
Mnyromyr's patch with my tabbrowser.xml changes (3.55 KB, patch)
2006-01-14 07:09 PST, neil@parkwaycc.co.uk
mnyromyr: review+
jag-mozilla: superreview+
csthomas: approval‑seamonkey1.1a+
Details | Diff | Splinter Review
Mac tab changes restricted to browser, for SM 1.0 (4.55 KB, patch)
2006-01-19 15:47 PST, Karsten Düsterloh
mnyromyr: review+
mnyromyr: superreview+
iann_bugzilla: approval‑seamonkey1.0+
Details | Diff | Splinter Review
mac patch for 1.1b (2.55 KB, patch)
2006-09-07 15:10 PDT, Stefan [:stefanh]
mnyromyr: review+
neil: superreview+
iann_bugzilla: approval‑seamonkey1.1b+
Details | Diff | Splinter Review

Description Karsten Düsterloh 2005-12-21 10:15:34 PST
Since bug 105885 is fixed, the shortcut keys for start of page/end of page (Ctrl-Home/Ctrl-End) do not work as expected anymore: instead, the current tab is moved to start/end of the tab strip!

Steps to reproduce:
- open some tabs, at least one not the last in the tab strip with text longer than the visible window (for ease of reproduction)
- focus this text tab
- press F7 to enter caret mode
- move caret amidst a line in the top part of the text
- press the End key and see the caret move to the end of the line
- move caret amidst a line in the top part of the text again
- press Ctrl+End and see the caret NOT move to the end of the entire text - instead the current tab is moved to the end of the tab strip!

This is very unexpected (if not §$%&#*! annoying), both on MS Windows and "Linux Windows" aka KDE. :(

Currently, Ctrl+<left> / Ctrl+<right> move the tab one position left/right, so do Ctrl+<up> / Ctrl+<down>.

Possible better shortcut keys:
- Ctrl+<up> / Ctrl+<down> to move current tab to start/end of tab strip
- Ctrl+Alt+Home / Ctrl+Alt+End
Comment 1 Karsten Düsterloh 2005-12-21 10:18:01 PST
Just a sidenote: caret mode is no real condition, it's just used for making the issue more visible. 
BTW: the patch for bug 105885 also caused a similar problem on Mac, bug 320161.
Comment 2 moz 2005-12-21 10:50:17 PST
> Possible better shortcut keys:
>   Ctrl+<up> / Ctrl+<down> to move current tab to start/end of tab strip

Let me add that Ctrl+<up> / Ctrl+<down> are used nowadays to go to the next tab / previous tab. Better if Ctrl+Alt+<up> / Ctrl+Alt+<down> are used (or another unused combinations)
Comment 3 moz 2005-12-21 10:51:53 PST
[Moving this text from https://bugzilla.mozilla.org/show_bug.cgi?id=320161]

This is a bug that causes a lot, a lot of confusion (at least to the users in
windows). 

If you are in a page and use Ctrl+Home you expect to go to the beginning of the
page/document (like in Mozilla Composer, Notepad, Word, Excel, Acrobat Reader
and so many other programs). 

But now in Seamonkey 1.0beta the user sees he remains in the same place, and
later sees that the tabs have changed!. Please, Ctrl+Home, Ctrl+End, Ctrl+Left,
Ctrl+Right and so on are heavily used in a lot of applications (including
Mozilla Composer), it's a great help to users to leave it as it always has been
in Seamonkey, Mozilla, Netscape... and assign it to some unused keys.
Comment 4 Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com] 2005-12-22 06:53:54 PST
ostgote@gmx.net changed:
           What    |Removed                     |Added
----------------------------------------------------------------------------
       Version|unspecified                 |1.8 Branch

Doesn't this bug affect trunk as well?
Comment 5 OstGote! 2005-12-22 07:10:28 PST
(In reply to comment #4)

Sure. Sorry.

Comment 6 Karsten Düsterloh 2005-12-22 07:45:47 PST
Another negative sideeffect of the key bindings of bug 105885 is their focus stealing: if you (accidentally) hit Ctrl+End and your tab gets moved, a subsequent End (if in non-caret mode) isn't working, either, because the focus is now upon the tab...
Comment 7 Karsten Düsterloh 2005-12-22 18:28:37 PST
Created attachment 206667 [details] [diff] [review]
use Ctrl+Alt as modifier and remember focus 

I changed the modifier from Ctrl to Ctrl-Alt, so Ctrl-Home etc. do work again. Furthermore, the tab moving functions now remember if the <tab> or the <browser> element was focused and keep the focus there.
Comment 8 Stefan [:stefanh] 2005-12-22 22:58:46 PST
Comment on attachment 206667 [details] [diff] [review]
use Ctrl+Alt as modifier and remember focus 

Hmm, in Camino/Firefox Cmd+Opt+Left/Right arrow is used for switching between tabs. I think we should implement that for SeaMonkey as well (had plans for it). The only thing that's left for mac that I can think of is Cmd+Shift+arrows. What might be confusing is that that combo is used in Safari for switching between tabs :/
Comment 9 Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com] 2005-12-23 07:52:34 PST
*** Bug 321330 has been marked as a duplicate of this bug. ***
Comment 10 Karsten Düsterloh 2005-12-23 13:11:34 PST
Created attachment 206728 [details] [diff] [review]
Mac-aware version

This version moves the key definitions into the platform-dependent files and changes the key combinations to Accel+Alt+Arrow/Home/End on Unix/Win and Accel+Shift+Arrow/Home/End on Mac. (Keys for switching tabs on Mac is beyond the scope of this bug.)
Comment 11 Xuân Baldauf 2005-12-24 18:39:47 PST
As Ctrl+Home|Ctrl+End are the very standard key combinations for navigating to the start|end of a document (at least under Windows), this issue should be resolved by reassigning exactly these keys combinations to their past actions (go to the start|end of the current document), these keys combinations should not serve any other purpose.
Comment 12 Stefan [:stefanh] 2005-12-26 05:51:25 PST
Hmm, do the mac text selection keys in content/xbl/builtin/mac/platformHTMLBindings.xml still works with this patch?
Comment 13 Karsten Düsterloh 2005-12-26 14:57:18 PST
> do the mac text selection keys [...] still works with this patch?

They do (for me, under OS X 10.4.3) - which keys don't work for you with this patch applied?
Comment 14 neil@parkwaycc.co.uk 2005-12-30 15:47:59 PST
For example, Mac uses Accel+Shift+Left to select to the beginning of the line.

Additionally note that Ctrl+Alt+End isn't available for Remote Desktop users.
Comment 15 Karsten Düsterloh 2006-01-03 18:53:00 PST
Created attachment 207465 [details] [diff] [review]
v3: toolkit-lookalike, with extra candy

After some longish discussions on IRC we came to the conclusion that the various key conflicts and inconsistencies caused and worsened by the patch for bug 105885 could only be sensibly resolved by following toolkit and restricting the tab moving keys to the tabstrip, i.e. they're only working now when the focus is inside the tab strip...
(This has the extra benefit of making our tabbrowser.xml less different from toolkit's.)
Mac's Classic theme had "-moz-user-focus: ignore", so I had to fix that, too.
Comment 16 Karsten Düsterloh 2006-01-04 10:28:32 PST
Created attachment 207516 [details]
Mac Classic tabs without and with focus rectangle
Comment 17 Stefan [:stefanh] 2006-01-04 10:39:30 PST
(In reply to comment #16)
> Created an attachment (id=207516) [edit]
> Mac Classic tabs without and with focus rectangle
> 

I guess we can't use the -moz-mac-focusring, since it's blue? Hmm, I think I prefer not having a focus rectangle.
Comment 18 Karsten Düsterloh 2006-01-04 11:12:18 PST
Well, the focus ring is only shown if the *tab* has the *keyboard* focus, not when the tab is selected. Usually, the web page has the keyboard focus until you voluntarily (e.g. Shift+Tab) move it into the tab strip. And we need a visualization of the keyboard focus in the tab strip else we don't know it's there...
(Modern does this on Mac with a very ugly fat border, btw.)
Comment 19 Stefan [:stefanh] 2006-01-05 07:09:18 PST
(In reply to comment #18)
> Well, the focus ring is only shown if the *tab* has the *keyboard* focus, not
> when the tab is selected. Usually, the web page has the keyboard focus until
> you voluntarily (e.g. Shift+Tab) move it into the tab strip. And we need a
> visualization of the keyboard focus in the tab strip else we don't know it's
> there...
> (Modern does this on Mac with a very ugly fat border, btw.)
> 
You could wrap everything in mac/global/globalBindings.xml#tab in  a <hbox class="tab-container"...> then add styles in browser.css (we just want this in browser tabs).

Something like this:

tab[selected="true"] {
  -moz-user-focus: normal;
}

.tab-container {
  border: 2px solid transparent;
}

tab:focus > .tab-container {
  border: 2px solid -moz-mac-focusring;
  -moz-border-radius-topleft: 2%;
  -moz-border-radius-topright: 2%;
}

It looks acceptable, might look even better with more tweaks.
Comment 20 Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com] 2006-01-06 11:44:48 PST
*** Bug 320161 has been marked as a duplicate of this bug. ***
Comment 21 jag (Peter Annema) 2006-01-06 13:10:41 PST
Comment on attachment 207465 [details] [diff] [review]
v3: toolkit-lookalike, with extra candy

I like the code changes, but I'm unsure about the look of the focused tab on Mac, though I'm willing to say let's live with it for a while and see if we can do better in a follow-up bug.
Comment 22 neil@parkwaycc.co.uk 2006-01-06 14:09:43 PST
Comment on attachment 207465 [details] [diff] [review]
v3: toolkit-lookalike, with extra candy

_keyEventHandler is a special "window" key event handler, a normal <handler> should suffice for events on the tabbrowser itself.

I'm not sure isTrusted is required any more, I thought chrome now ignores trusted events unless specifically asking for them.

Should the mac tab focus changes only apply to tabbrowser tabs, not all tabs?
Comment 23 Karsten Düsterloh 2006-01-06 14:57:24 PST
> _keyEventHandler is a special "window" key event handler, a normal <handler>
> should suffice for events on the tabbrowser itself.

Well, I didn't invent it here, and it's used in toolkit, too. I can change it, but I doubt the usefulness, especially in the light of bug 282178. 

> I'm not sure isTrusted is required any more, I thought chrome now ignores
> trusted events unless specifically asking for them.

Dunno.

> Should the mac tab focus changes only apply to tabbrowser tabs, not all tabs?

IMO, they should apply to all tabs, that's why I made the changes in Mac's tabbox.css and not in its browser.css. And based on comment 19, I'd change the tab:focus rule of attachment 207465 [details] [diff] [review] to:

tab:focus > .tab-image-middle {
  outline: 2px solid -moz-mac-focusring;
  outline-offset: -2px;
  -moz-outline-radius-topleft:  2%;
  -moz-outline-radius-topright: 2%;
}


Comment 24 Karsten Düsterloh 2006-01-06 15:02:50 PST
Created attachment 207766 [details]
Mac Classic tabs with -moz-mac-focusring rectangle (see comment #23)
Comment 25 neil@parkwaycc.co.uk 2006-01-06 16:22:45 PST
(In reply to comment #23)
>>_keyEventHandler is a special "window" key event handler, a normal <handler>
>>should suffice for events on the tabbrowser itself.
>Well, I didn't invent it here, and it's used in toolkit, too. I can change it,
>but I doubt the usefulness, especially in the light of bug 282178.
I had thought that bsmedberg wanted to take tabbrowser out of toolkit...

>>I'm not sure isTrusted is required any more, I thought chrome now ignores
>>trusted events unless specifically asking for them.
>Dunno.
Also, content will find it hard to generate events whose originalTarget is the tabbrowser's current tab...

>>Should the mac tab focus changes only apply to tabbrowser tabs, not all tabs?
>IMO, they should apply to all tabs, that's why I made the changes in Mac's
>tabbox.css and not in its browser.css.
OK, that's fine assuming jag's happy with the latest CSS.
Comment 26 neil@parkwaycc.co.uk 2006-01-06 16:27:06 PST
Comment on attachment 207465 [details] [diff] [review]
v3: toolkit-lookalike, with extra candy

And not forgetting the unnecessary 'in' tests. And the incorrect way of verifying the event target.
Comment 27 Stefan [:stefanh] 2006-01-07 10:08:00 PST
> 
> > Should the mac tab focus changes only apply to tabbrowser tabs, not all tabs?
> 
> IMO, they should apply to all tabs, that's why I made the changes in Mac's
> tabbox.css and not in its browser.css.

IMO, I don't see the point applying it for all tabs. Why does non-browser tabs need this change?
Comment 28 Stefan [:stefanh] 2006-01-07 12:39:36 PST
Created attachment 207843 [details] [diff] [review]
Using a tab-container

This is what I ment in comment #19.
Comment 29 Stefan [:stefanh] 2006-01-07 13:02:17 PST
Created attachment 207845 [details]
Screentshot of attachment #207843 [details] [diff] [review] in action

Ideally, I would want the focus-ring to cover all tab-borders, but this one is acceptable IMO. Note that I haven't seen *any* mac app that actually have this (but I might be totally wrong here, of course). Well, firefox has it in browser tabs - but they're not native-styled. Camino doesn't show any focus-ring in browser tabs (and Camino's browser tabs are not native).
Comment 30 Stefan [:stefanh] 2006-01-09 05:57:15 PST
> Note that I haven't seen *any* mac app that actually have this
> (but I might be totally wrong here, of course).

Actually I was wrong. If you enable full keyboard access in system prefs it's possible to focus a native tab - the tab gets a "focus ring" when it has kbd focus.
Comment 31 Karsten Düsterloh 2006-01-12 15:22:39 PST
Created attachment 208312 [details] [diff] [review]
v4: (most) comments addressed

Changes to v3:
- using a more Macish keyboard focus rectangle, without the need for extra hboxes
  (Mac-only; and I'm not guilty of 323206 ;-) )
- wrt the _keyEventHandler: the ^F4 key is meant to be a global key, so the field 
  needs to stay - but with the field in place, the tabbrowser doesn't get the
  keypress events... So I left that as is.
- removed the isTrusted check
- removed the 'in' checks
- fixed target check
Comment 32 Karsten Düsterloh 2006-01-12 15:26:47 PST
Created attachment 208314 [details]
v4 Mac keyboard focus
Comment 33 neil@parkwaycc.co.uk 2006-01-14 07:09:35 PST
Created attachment 208476 [details] [diff] [review]
Mnyromyr's patch with my tabbrowser.xml changes
Comment 34 neil@parkwaycc.co.uk 2006-01-14 07:10:41 PST
Comment on attachment 208312 [details] [diff] [review]
v4: (most) comments addressed

But see attachment 208476 [details] [diff] [review].
Comment 35 Karsten Düsterloh 2006-01-15 12:08:47 PST
Comment on attachment 208476 [details] [diff] [review]
Mnyromyr's patch with my tabbrowser.xml changes

I did try such handlers, but they didn't work - I wonder what went wrong. Anyway, this works fine (and we should take it instead then), with just one side effect: the key handlers need to stop the event propagation and default processing, because e.g. Accel+Home is "open new tab with home page" on Mac, too. This patch moves the tab to position 1 and opens a new tab, too...
r=me with that.
Comment 36 jag (Peter Annema) 2006-01-16 23:38:17 PST
Comment on attachment 208476 [details] [diff] [review]
Mnyromyr's patch with my tabbrowser.xml changes

sr=jag if you make those changes Mnyromyr pointed out.
Comment 37 neil@parkwaycc.co.uk 2006-01-17 09:27:13 PST
Fix checked in to the trunk.
Comment 38 Karsten Düsterloh 2006-01-17 12:24:16 PST
Comment on attachment 208476 [details] [diff] [review]
Mnyromyr's patch with my tabbrowser.xml changes

The most importantly thing is *not* to release 1.0 *without* the checked-in version of this...
Comment 39 Mark Banner (:standard8) 2006-01-17 14:14:45 PST
My latest trunk build is now coming up with:

XML Parsing Error: not well-formed
Location: jar:resource:///chrome/toolkit.jar!/content/global/bindings/tabbrowser.xml
Line Number 1844, Column 148:
      <handler event="keypress" keycode="VK_RIGHT" modifiers="accel" action="if (event.target == this) { this.moveTabRight();" event.preventDefault(); }/>
---------------------------------------------------------------------------------------------------------------------------------------------------^

Looks like a missing "
Comment 40 Karsten Düsterloh 2006-01-17 22:45:06 PST
> Looks like a missing "

Actually, it was just misplaced - and Neil corrected it already on trunk... 

Comment 41 Stefan [:stefanh] 2006-01-19 09:36:42 PST
I am a bit sceptical of the mac tab changes - that is, that they apply to all tabs rather than just browser tabs.

Focus in non-browser tabs just seem to behave rather odd now. For instance:

1) The "main" tab in Page Info have now has a focus-ring when the window is opened. I would rather expect the content to have focus (yes, you can switch tabs even if content have focus).

2) If you put focus on a tab in Chatzilla and start to switch tabs, you lose the focus-ring after the first switch - switching works fine without focus, though.

3) Before the patch focus didn't leave the content area if you clicked on a active tab in Composer. Now it does - but the only effect of focusing the tab is that I lose focus in content and the focus-ring appear around the tab (and the focus-ring doesn't look that nice in bottom-tabs). The issue here is that I don't seem to be able to get back focus in the content area using the tab key (have to use my pointing device).

Comment 42 Karsten Düsterloh 2006-01-19 15:47:58 PST
Created attachment 209029 [details] [diff] [review]
Mac tab changes restricted to browser, for SM 1.0

I agree with stefanh that we shouldn't deliver SM 1.0 with the side effects he mentioned, so I put together this patch *for checkin on MOZILLA_1_8_0_BRANCH only*, which does the Mac focus changes only for the browser tab strip - otherwise it's the changes already checked in on trunk.
That'd leave with enough time to fix the other issues for 1.1.
Carrying over r/sr and asking for Council approval for this temporary solution.
Comment 43 Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com] 2006-01-19 15:58:28 PST
(In reply to comment #42)
> Created an attachment (id=209029) [edit]
> Mac tab changes restricted to browser, for SM 1.0
> 

first a=me for 1.0, need one more
Comment 44 Ian Neal 2006-01-19 17:00:35 PST
Comment on attachment 209029 [details] [diff] [review]
Mac tab changes restricted to browser, for SM 1.0

a=me for SM1.0, one more to go
Comment 45 Ian Neal 2006-01-19 17:01:57 PST
Comment on attachment 209029 [details] [diff] [review]
Mac tab changes restricted to browser, for SM 1.0

ok, now sssh I didn't see CTho's comment
Comment 46 Karsten Düsterloh 2006-01-21 15:38:03 PST
Checked attachment #209029 [details] [diff] [review] into 1.8.0 branch.
Comment 47 Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com] 2006-01-22 14:15:57 PST
setting status whiteboard based on keywords
Comment 48 Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com] 2006-04-16 09:46:24 PDT
*** Bug 320842 has been marked as a duplicate of this bug. ***
Comment 49 Stefan [:stefanh] 2006-09-07 13:13:02 PDT
(In reply to comment #42)
> Created an attachment (id=209029) [edit]
> Mac tab changes restricted to browser, for SM 1.0
> 
> I agree with stefanh that we shouldn't deliver SM 1.0 with the side effects he
> mentioned, so I put together this patch *for checkin on MOZILLA_1_8_0_BRANCH
> only*, which does the Mac focus changes only for the browser tab strip -
> otherwise it's the changes already checked in on trunk.
> That'd leave with enough time to fix the other issues for 1.1.
> Carrying over r/sr and asking for Council approval for this temporary solution.
> 

Karsten and I talked on irc about the mac situation for 1.1. We came to the conclusion that the 1.8 branch should also restrict the mac focus changes to only the tab strip. That is, the changes in classic/global/tabbox.css should be backed out and the browser.css part of attachment #209029 [details] [diff] [review] should be applied to the 1.8 branch.
Comment 50 Stefan [:stefanh] 2006-09-07 15:10:16 PDT
Created attachment 237195 [details] [diff] [review]
mac patch for 1.1b
Comment 51 Stefan [:stefanh] 2006-09-08 08:45:12 PDT
Comment on attachment 237195 [details] [diff] [review]
mac patch for 1.1b

OK, so I've tested this. And it works as expected.
Comment 52 Karsten Düsterloh 2006-09-09 13:22:19 PDT
Comment on attachment 237195 [details] [diff] [review]
mac patch for 1.1b

Checked in into MOZILLA_1_8_BRANCH.

Note You need to log in before you can comment on or make changes to this bug.