Closed Bug 1226102 Opened 4 years ago Closed 3 years ago

Browser: F6 always selects sidebar first, then next frame couter-clockwise

Categories

(SeaMonkey :: General, defect)

SeaMonkey 2.39 Branch
Unspecified
All
defect
Not set

Tracking

(seamonkey2.44 wontfix, seamonkey2.45 fixed, seamonkey2.46 fixed, seamonkey2.47 fixed, seamonkey2.48 fixed)

RESOLVED FIXED
Tracking Status
seamonkey2.44 --- wontfix
seamonkey2.45 --- fixed
seamonkey2.46 --- fixed
seamonkey2.47 --- fixed
seamonkey2.48 --- fixed

People

(Reporter: therubex, Assigned: frg, NeedInfo)

References

Details

Attachments

(1 file)

Place focus on a web page (even about:blank).
Press F6.

Results:
Focus remains in the current tab.
(Note that a frame is placed around it window tab.)

Press F6, again.
At that point, after a second press of F6, focus jumps to the address  bar.


Expected:
Focus should be placed on the address bar (or next frame in the existing tab).

As it is now, pressing F6 to focus on the address bar requires at least two consecutive F6's.
 
 
This is a regression from SeaMonkey 2.38.
FF 42 does not seem to be affected.
(In reply to therube from comment #0)
> Expected: Focus should be placed on the address bar 
> (or next frame in the existing tab).

Why (Help text, other specification)? Focus on URL-Location-bar is <alt+d>, not <f6>

I indeed see a difference between versions:

test with  SeaMonkey German 2.39 final Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0 from official download area)  Gecko/20100101  Firefox/42.0  Build 20151103191810  (Classic Theme) on German WIN7 64bit
1. Launch Browser → show Sidebar / Bookmarks + few TABs, one of them
  <http://www.seamonkey-project.org/releases/seamonkey2.35/>
2. on SM2.35 page doubleclick “Downloading”
3. press <f6> several times
   » you will see moving focus COUNTER-clockwise bookmarks → website contents →
     Location-bar → bookmarks → and so on
4. press <shift+f6> several times
   » you will see rotating focus CLOCKwise
5. do the same test  with FF 45.0a1 (2015-11-29)
 » you will see  COUNTER-clockwise direction of rotation as in SM
   but it starts always with next frame from focus, while SM from
   website contents jumps to bookmarks (sidebar)
6. Test direction of rotation in SM mail client with 3 panes open: REVERSE to 
   step 3, 4

Test with German SeaMonkey 2.35 (Windows NT 6.1; WOW64; rv:38.0)  Gecko/20100101 Build 20150827182544 (Classic Theme) on German WIN7 64bit:

11. Launch Browser → show Sidebar / Bookmarks + few TABs, one of them
  <http://www.seamonkey-project.org/releases/seamonkey2.35/>
12. on SM2.35 page doubleclick “Downloading”
13. press <f6> several times
   » you will see moving focus CLOCKwise bookmarks → website contents →
     Location-bar → bookmarks → and so on
14. press <shift+f6> several times
   » you will see rotating focus COUNTER-clockwise
15. ./.
16. Test direction of rotation in SM mail client with 3 panes open: SAME
    as in step 13, 14

Test with FF 40.0.3
25. Do Step 3 Test 
   » you will see moving focus COUNTER-clockwise bookmarks → website contents →
     Location-bar → bookmarks → and so on

BTW: 
a) TB 45.0a1 (2015-11-20): <f6>= CLOCKwise
b) SM Address book (2.39): <f6>= CLOCKwise
c) SM-Chatzilla 2.39: <f6>=  COUNTER-clockwise (what might be inconsistent

   Whatever this all might mean.

d) I think the inconsistency between 2.39 Browser and all other 2.39-apps
   is not a good idea.  
e) Is there and “technical rule” concerning with/without shift and clockwise or
   counter clocwise: 
e1) I found several indications for “clockwise without shift”: 
   <https://support.office.com/en-in/article/Keyboard-shortcuts-for-Visio-ee952f31-7e3e-4564-8116-f3ecbb733cc1>
<https://www.rnib.org.uk/sites/default/files/microsoft_word_2013_keyboard_shortcuts.docx>
e2) no hints for “counter-clockwise without shift”:
   (That is a very small sample)
f) I think we will have to decide: <f6> (without shift) clockwise or 
   counter-clockwise?
g) Additionally we might have a (separate?) issue that in browser always the 
   first <f6> goes to sidebar, we should open a separate issue for that.

@therube 
Any ideas concerning a technical rule what might ease our decisions?
Status: NEW → UNCONFIRMED
Ever confirmed: false
Flags: needinfo?(therubex)
OS: Unspecified → Windows 7
Summary: F6 Focus Issue - If current focus is in a page, F6 first focuses on the page, again, before advancing to address bar/frames → Browser (and Chatzilla): F6 selects next frame couter-clockwise
h) Chatzilla-counter-clockwise-rotation: separate issue!
i) Counter-clockwise- AND “first to sidebar”-issue already REPRODUCIBLE with  
   SeaMonkey 2.39a1 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0 from 
   official download area)  Gecko/20100101  Firefox/42.0  Build 20150721221150
  (Classic Theme) on German WIN7 64bit
k) both issues from (i) still ok with  en-US SeaMonkey  2.38  
   (Windows NT 6.1; WOW64; rv:41.0)  Gecko/20100101 Firefox/41.0 
   Build 20150923195647  (Classic Theme) on German WIN7 64bit
l) Even if the decision will be to follow the counter-clockwise-rotation of FF, 
   for good reasons, the "Sidebar-First"-issue should be fixed.
Summary: Browser (and Chatzilla): F6 selects next frame couter-clockwise → Browser: F6 selects next frame couter-clockwise
Here we have 2 issues:
g): <f6> always first changes focus to sidebar (even if hidden)
   (main issue)
f): newly <f6> selects frames counter clockwise (bug or feature?)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Browser: F6 selects next frame couter-clockwise → Browser: F6 always selects sidebar first, then next frame couter-clockwise
g1): "<f6> always first changes focus to sidebar" only appears if caret is
     not in an input line. Example this page:
     - if caret is in comment input field, <f6> leads to location bar   :-)
     - if a word in Comment 3 is selected, <f6> leads to sidebar        :-(
All the same REPRODUCIBLE with  English SeaMonkey 2.42a1  (X11; Linux x86_64; rv:45.0)  Gecko/20100101 Firefox/45.0 Build 20151103003001  (Classic Theme) on VirtualBox Ubuntu 14.04 LTS
(I did not compare with older SeaMonkey Linux versions)
OS: Windows 7 → All
(In reply to Rainer Bielefeld from comment #3)
> Here we have 2 issues:
> g): <f6> always first changes focus to sidebar (even if hidden)
>    (main issue)
> f): newly <f6> selects frames counter clockwise (bug or feature?)
NI Neil
Flags: needinfo?(neil)
So, it looks like there used to be a bug whereby focus went to the sidebar after the page instead of before, which has since been fixed, but there's a new bug whereby focus always starts on the web page rather than in the focused frame.
Firefox isn't affected by that bug, so there's something that we're not doing right... I think it's in focusNextFrame() where we're passing window to moveFocus and it probably wants the focused window.
Flags: needinfo?(neil)
We probably need to port part of Bug 1132518 ([e10s] Document navigation with F6 doesn't work) specifically https://hg.mozilla.org/mozilla-central/rev/87f44cd6e7f0
Flags: needinfo?(neil)
(In reply to Philip Chee from comment #8)
> We probably need to port part of Bug 1132518 specifically
> https://hg.mozilla.org/mozilla-central/rev/87f44cd6e7f0

Oh, that works too, I guess.
Flags: needinfo?(neil)
(In reply to neil@parkwaycc.co.uk from comment #7)
> So, it looks like there used to be a bug whereby focus went to the sidebar
> after the page instead of before, which has since been fixed, but there's a
> new bug whereby focus always starts on the web page rather than in the
> focused frame.
> Firefox isn't affected by that bug, so there's something that we're not
> doing right... I think it's in focusNextFrame() where we're passing window
> to moveFocus and it probably wants the focused window.
Don't you mean the focused _frame_?
(In reply to Philip Chee from comment #10)
> (In reply to comment #7)
> > So, it looks like there used to be a bug whereby focus went to the sidebar
> > after the page instead of before, which has since been fixed, but there's a
> > new bug whereby focus always starts on the web page rather than in the
> > focused frame.
> > Firefox isn't affected by that bug, so there's something that we're not
> > doing right... I think it's in focusNextFrame() where we're passing window
> > to moveFocus and it probably wants the focused window.
> Don't you mean the focused _frame_?
Yes, but the API is document.commandDispatcher.focusedWindow and frames are windows... not that it matters if you port bug 1132518.
I can change a few lines. Hopefully the right ones :)

Quickly tested on c-a only because c-c is currently broken with VS2015 Update 3. 

Focus switches from tab to location bar first and then to sidebar.
Assignee: nobody → frgrahl
Status: NEW → ASSIGNED
Attachment #8774550 - Flags: review?(iann_bugzilla)
Comment on attachment 8774550 [details] [diff] [review]
1226102-F6-focus.patch

[Triage Comment]
r/a=me for all
Attachment #8774550 - Flags: review?(iann_bugzilla)
Attachment #8774550 - Flags: review+
Attachment #8774550 - Flags: approval-comm-release+
Attachment #8774550 - Flags: approval-comm-beta+
Attachment #8774550 - Flags: approval-comm-aurora+
Duplicate of this bug: 1313638
You need to log in before you can comment on or make changes to this bug.