focussing a hyperlink by (left-/right-)clicking does not collapse/unfocus existing selection (highlighted text or caret cursor), causing double focus with mixed or no context menu on the link

NEW
Unassigned

Status

()

Core
Event Handling
8 years ago
7 months ago

People

(Reporter: Thomas D., Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments)

(Reporter)

Description

8 years ago
Created attachment 406712 [details]
Screenshot: Bogus focus after click on link (with highlighted text)

STR:

1) select any text on a given html page or mail (for greater confusion, highlight caption of a link)
2) right-click on a link somewhere else on the page
3) alternatively, left-click on a link

Expected
2) selection (highlighted text with blue background) should be collapsed, as the focus is now on the link
3) same as in 2

Actual
2) a) selection is NOT collapsed; this leads to
b) bogus focus context menu shows up, with commands for both the link and the highlighted text
- "copy" command will copy highlighted text
- "copy link location" will copy link of focused link
- iow, we have (visual and functional) double focus (wrong)
- which causes context menu to show commands for 2 completely unrelated spots of the page

Expected
2)+3) (left-/right-)clicking anywhere outside selected text must collapse the selection before proceeding -> no double focus -> no bogus context menus

Comment 1

8 years ago
I think that current behavior is right.

>Expected
>2)+3) (left-/right-)clicking anywhere outside selected text must collapse the
>selection before proceeding -> no double focus -> no bogus context menus

NO.
It is very troublesome to return mouse pointer on a text done a highlight of after having chosen it by the drag of the mouse. I will be in particular difficult in laptop (trak pad).
(Reporter)

Comment 2

8 years ago
Created attachment 406750 [details]
Screenshot 2: Double focus after click on link (with messy context menu) [has STR]

(In reply to comment #1)
Alice, thanks for immediate reply. This helps to clarify the bug.

> >Expected
> >2)+3) (left-/right-)clicking anywhere outside selected text must collapse the
> >selection before proceeding -> no double focus -> no bogus context menus
> NO.
> It is very troublesome to return mouse pointer on a text done a highlight of
> after having chosen it by the drag of the mouse. I will be in particular
> difficult in laptop (trak pad).

You are half right here, although I don't fully understand what you mean.
I must correct expected behaviour:

Expected behaviour:
2)+3) if (left-/right-)clicking outside selected text *on the same document* creates a new keyboard focus (as when you click on a link), we must collapse the text selection before proceeding -> no double focus -> no bogus context menus that combine commands for two different foci (so user has to guess which command refers to which focus)

> I think that current behavior is right.
Please have a look at the annotated screenshot to see that this behaviour definitely is NOT right. The context menu was opened from the link(!), so the commands of that context menu can usually only refer to the focussed link (or to other things that are generally known, like print etc.). Otherwise, it would be completely unpredictable what "Copy" will do in this situation: will it copy the (caption of) focussed link? or will it copy the selected text?

Just imagine selected text could be 100 lines down from the link which now has focus. Then "copy" from the context menu of the focussed(!) link on top copies the text which isn't even in sight?

Another problem with double focus is that it's unpredictable where keyboard input will go to:
- pressing <enter> or <context menu key> will act on the focussed link (1st focus)
- but pressing <ctrl+c> will unexpectedly act on the selected text

When a link has visible focus (dotted border), pressing <ctrl+c> should copy the link (as requested in  Bug 462761 - Message Reader: Focused hyperlinks in msgs should be copyable with Ctrl+C, if there is no text selected/highlighted)

I'll attach another annotated screenshot which makes the problem of double focus and unpredictable redirection of keyboard input even more obvious.
(Reporter)

Comment 3

8 years ago
Created attachment 406761 [details]
Screenshot 3: Double focus after click on link with caretBrowsing (<context key> not possible for link in focus) [has STR]

(In reply to comment #2)
> I'll attach another annotated screenshot which makes the problem of double
> focus and unpredictable redirection of keyboard input even more obvious.

As announced, here's another variant of this, showing more clearly the problems.
Again, because of double focus user has no way of predicting where his keyboard inputs will actually go to.

STR (http://www.mozilla.org/)
1) accessibility.browsewithcaret = true (F7)
2) move cursor onto “Thunderbird” link (using cursor keys)
-> TB link is focused (dotted border)
3) right-click on FF image link, then ESC
-> FF img link is focused (dotted border)
-> but caret cursor focus still on “Thunderbird”
-> double focus (bug!). See double focus at work, as you now press different keys:

4) press <Enter>: keyboard input goes to focus 1 (FF logo link)
-> from dotted img link focus, FF link is opened
(then press <backspace> to return)

5) press <context menu key>: keyboard input goes to focus2 (“Thunderbird” link)
(still from the same situation as before 4!)
-> from parallel caret focus, you get TB link context menu

-> Depending on which key you press, either of the two simultaneous foci will get the action
-> unpredictable UI (bug)

Expected / Solution:
5) <context menu key> should open the context menu of FF link in focus(!), as it has dotted border
• Focus always follows mouse clicks, i. e.
- when we (left-/right-)click on link, only focus must be on link
- caret cursor must be moved in front of link (just as we currently do when you tab through links)
(Reporter)

Comment 4

8 years ago
Created attachment 406772 [details]
Screenshot 4: Double focus guess game (with two links having focus)

(In reply to comment #0)
>1) ... (for greater confusion, highlight caption of a link), then right-click > on another link, press ESC

Finaly, here's the double link double focus guessgame scenario for advanced confusion. Sorry for comment overload, I just wanted to get this out of the way.

(In reply to comment #2
> Another problem with double focus is that it's unpredictable where keyboard
> input will go to:
> - pressing <enter> or <context menu key> will act on the focussed link (1st
> focus)
> - but pressing <ctrl+c> will unexpectedly act on the selected text
> 
> When a link has visible focus (dotted border), pressing <ctrl+c> should copy
> the link (as requested in  Bug 462761 - Message Reader: Focused hyperlinks in
> msgs should be copyable with Ctrl+C, if there is no text selected/highlighted)
(Reporter)

Updated

8 years ago
Summary: (left-/right-)clicking on a hyperlink does not collapse existing selection (highlighted text), leading to bogus context menu commands on the link (e.g. copy) → focussing a hyperlink by (left-/right-)clicking does not collapse/unfocus existing selection (highlighted text or caret cursor), causing double focus with mixed or no context menu on the link

Comment 5

8 years ago
(In reply to comment #2)
> Expected behaviour:
> 2)+3) if (left-/right-)clicking outside selected text *on the same document*
> creates a new keyboard focus (as when you click on a link), we must collapse
> the text selection before proceeding -> no double focus -> no bogus context
> menus that combine commands for two different foci (so user has to guess which
> command refers to which focus)


STR1
1) Select partial text of a anchor element
2) Right-click on the anchor element

STR2
1)Select text include some anchor elements
2)Right-click on one of the anchor elements of the above

it should not be collapsed the selection even if a mouse comes off from a highlight a little.

Comment 6

8 years ago
If I wants to copy clipboard text like '<a href="link url">selected text</a>'by using MakeLink  extension etc. 
1) Select text
2) Right-click on link.

in this case,  1) should not be collapsed.

Comment 7

8 years ago
Google Chrome and Internet Explorer7 on Windows Vista,
They are as same as the current behavior of Firefox.

STR:
1) select any text on a given html page
2) right-click on a link somewhere else on the page

The selection does not collapse.
link and selection menu is display both.

Opera10 is slightly different.
The selection does not collapse.
But Only link menu is displayed
(Reporter)

Comment 8

8 years ago
(In reply to comment #5)
Alica, thanks again for your helpful comments.

> (In reply to comment #2)
> > Expected behaviour:
> > 2)+3) if (left-/right-)clicking outside selected text *on the same document*
> > creates a new keyboard focus (as when you click on a link), we must collapse
> > the text selection before proceeding -> no double focus -> no bogus context
> > menus that combine commands for two different foci (so user has to guess
> > which command refers to which focus)
 
> STR1
> 1) Select partial text of a anchor element
> 2) Right-click on the anchor element

.........................
: Link /\Caption #Text##:####Selected Text outside link###############
........\................
You are right, this is an edge case where selected text and link have an intersection. Maybe in this case, we don't need to collapse the selection when user clicks on non-selected half of the link. I'm more worried about those cases where the focussed link and the selected (i.e. focussed) text do NOT intersect.

> STR2
> 1)Select text include some anchor elements
> 2)Right-click on one of the anchor elements of the above
> 
> it should not be collapsed the selection even if a mouse comes off from a
> highlight a little.
                                          .............
Link1  unselected text  ###selected text##:##Link2#/\#:######
------                                    ..........\..

Thanks for pointing out this scenario. I think we quite agree here.
In the above example, you are right:
- right-clicking on link2
- or even right-clicking on "unselected text"
-> should not collapse the selection.

- However, IMO right-clicking on link1
-> should collapse the selection, because it creates a new visual focus indicator (dotted border occurs on link1):

..........                                
:Link1 /\: unselected text  [now un]selected text Link2
........\.                                        ------

What do you think about the above behaviour, could you accept that?

(In reply to comment #7)
> Google Chrome and Internet Explorer7 on Windows Vista,
> They are as same as the current behavior of Firefox.
> Opera10 is slightly different. The selection does not collapse.
> But Only link menu is displayed

True, but that doesn't necessarily mean the behaviour is right.
But you are right, it's not as straightforward as I thought.

Alica, what's your expection for screenshot3 which involves caret browsing? (attachment 406761 [details]):
.........
: Link1 :  unselected text Lin|k 2
.........                  ---------

Do you think the following is good behaviour?
- when user clicks <context menu key> on a focussed link1 (dotted border)
-> we don't show the context menu of link1
-> we show the context menu of link2 under caret cursor (no dotted border, no text selected)
(Reporter)

Comment 9

8 years ago
In last scenario, you can't use IE as an excuse, for IE does not have caret browsing... ;)
(Reporter)

Comment 10

8 years ago
(In reply to comment #9)
> In last scenario, you can't use IE as an excuse, for IE does not have caret
> browsing... ;)
Ops, IE8 *does* have caret browsing (F7).
IE8 also has the desired behaviour in dealing with the scenario of screenshot3 (attachment 406761 [details]).
(Reporter)

Comment 11

8 years ago
(In reply to comment #8)
>                                           .............
> Link1  unselected text  ###selected text##:##Link2#/\#:######
> ------                                    ..........\..
>
> - However, IMO right-clicking on link1
> -> should collapse the selection, because it creates a new visual focus
> indicator (dotted border occurs on link1):
> 
> ..........                                
> :Link1 /\: unselected text  [now un]selected text Link2
> ........\.                                        ------
> 
> What do you think about the above behaviour, could you accept that?

Again, IE 8 has the desired behaviour, BUT ONLY when you activate Caret Browsing (F7) (first time ever where IE seems to behave better than FF ;).
Without Caret Browsing, IE8 behaviour is also different from FF, but worse:
- right-clicking on link outside of selection: will NOT collapse (as current FF)
- right-clicking on text outside of selection: WILL collapse (unlike current FF)
Which seems to be the opposite of what I want.
You need to log in before you can comment on or make changes to this bug.