170921 - image maps select whole image when tabbed to

Status: VERIFIED FIXED

(Core :: DOM: Selection, defect)

Description

[mjudge]

If you tab to the image map on this webpage, the whole image is selected.
This is due to the desired behavior that the next tab should jump off of the 
last selection point.  We can do this however without moving the selection 
(thus not selecting the image unless desired) by making the nsEventStateManager 
have the ability to listen to selection notifications.  When the selection is 
moved (by themouse or keyboard or the Find dialog box for example) it notifies 
the eventstatemanager which then marks down that the next time a "tab" focus 
change is required to use the selection as a jump off point.  it then turns 
this flag off so that the subsequent calls to the "tab" focus change work off 
of the tab index (until the selection is moved again of course).

This also removes the requirement of the generichtmlelement from moving the 
selection when it is focused, the same with the similar code in 
nsEventStateManager.  

I think this is the best of all worlds.  As a coincidence IE has this behavior 
that the patch i will post makes.

Comment 1

[mjudge]

Attachment: from the y:\mozilla dir. patches layout and content

fixes above issue.  Also removes old fashioned call for HRFrame to draw itself.

The event state manager could use some more packed bools, but i just followed
suit and used a PRBool.  I could make then all packed bools.. anyone care?

Comment 2

[Tuukka Tolvanen (sp3000)]

*** Bug 169004 has been marked as a duplicate of this bug. ***

Comment 3

[mjudge]

updated status. i need a review/ super review. 

Comment 4

[Aaron Leventhal]

I tested this patch and looked it over. Here are some problems with it:

1. Doesn't work in case where you're focused on area element, use Ctrl+F to find
text, then tab. It should tab relative to the selection then, but it moves
relative to the area. Pretty easy to fix.
2. Doesn't work with find as you type where you tab to a link and then search,
the search doesn't start from the focused link as one would expect. Can be fixed.
3. Doesn't work with find as you type where you hit tab after you find some
text. It focuses the new link, but it's also supposed to clear the selection and
cancel the current find. This would require making find as you type a focus listener
4. I don't know, but it could cause other subtle problems with find as you type,
and other parts of our code which have evolved to expect the selection to move
with the focus.

Because the fix for problem 3 would be fairly involved, I'm leaning toward just
making MoveCaretToFocus not put the selection in front of an area element.

Mike, Brian, what do you think?

Comment 5

[Aaron Leventhal]

Attachment: A different approach designed to maintain our current behavior. Make sure leaf nodes like images, input elements and areas don't get selected by using SetStartBefore/SetEndBefore

Comment 6

[Brian Ryner (not reading)]

Comment on attachment 116495 [details] [diff] [review]
A different approach designed to maintain our current behavior. Make sure leaf nodes like images, input elements and areas don't get selected by using SetStartBefore/SetEndBefore

Sounds ok to me.

Comment 7

[Aaron Leventhal]

checked in

Comment 8

[sairuh (rarely reading bugmail)]

vrfy'd fixed with 2003.03.13 comm trunk on all platforms. tabbing no longer
selects entire image --now draws focus ring over the linked portions of the
image map.