133874 - unfocusing a link should remove url from status bar

Status: RESOLVED FIXED

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

Description

[Jesse Ruderman]

Steps to reproduce:
1. Go to http://www.google.com/.
2. Tab to "Images" (a link to http://www.google.com/imghp?hl=en)
3. Shift-tab. (Focuses the page)
4. Shift-tab. (Focuses the URL bar)

Result: at 3 and 4, the status bar still shows http://www.google.com/imghp?hl=en.

Expected: show "Done (0.33 secs)" or nothing.

This also happens when tabbing from a link to a form element, such as the Google
search textbox.

Comment 1

[Roland Unger]

Related to this bug, onfocus and onblur do not work correctly:
<a ... onfocus="window.status='string';return false"
       onblur="window.status='';return false">
Often nothing is done, after pressing tab key you can see
only the URL of the previuos link in the status bar. It seems
that onfocus works only in the case that the statusbar is empty
(and no link was (previously) focused).

I propose to change the severity to normal, because onfocus
and onblur are the alternative attributes to onmouseover and
onmouseout in case of using the keyboard. The correct working
is necessary for web accessibilty reasons for handicapped
persons.

For a solution, maybe see also bug 38380 (css a:hover ignored
on link with javascript "onMouseover" and "return true;")

Comment 2

[Jesse Ruderman]

Attachment: patch

This fixes the bug, but it makes "Document: Done" appear for a split-second if
you tab from one link to another (at least in Mozilla+Modern).	That already
happens if you move the mouse between two adjacent links, but it's not as much
of a problem with the mouse because adjacent links are rare and because it's
hard to look at the status bar while moving the mouse from link to another. 
I'll post a testcase with two adjacent links so other people can see what the
flicker looks like without applying the patch.

Comment 3

[Jesse Ruderman]

Attachment: testcase with two adjacent links and a textbox

The flicker is almost undetectable with this morning's nightly on my newish
Win2k computer.  It's easy to see in a debug build.

Comment 4

[Jesse Ruderman]

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

Comment 5

[Aaron Leventhal]

-> jesse

Comment 6

[Dimitrios]

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

Comment 7

[[e-mail]]

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

Comment 8

[Peter Kasting]

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

Comment 9

[Peter Kasting]

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

Comment 10

[Peter Kasting]

Attachment: patch v1

This is basically the same patch as Jesse's, just 4 years later.  I no longer see any flicker on mouse movement _or_ tabbing with his testcase.

Comment 11

[[e-mail]]

Note that the proposed patch still doesn't work when script refocuses during a focus event. smaug, got any ideas as to how to fix that case?

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

I think in NS_FOCUS_CONTENT case there should be a check like this:
(ESM->GetFocusedContent(...) == nsnull || ESM->GetFocusedContent(...) == this)
and only trigger link in that case.

Comment 13

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 230065 [details] [diff] [review]
patch v1

Moving this over to smaug since he's the expert on this.

Comment 14

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 230065 [details] [diff] [review]
patch v1

wrong smaug :)

Comment 15

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 230065 [details] [diff] [review]
patch v1

This should be ok, but please file a new bug for focus event handling or leave this bug open to fix that too.

Comment 16

[Peter Kasting]

Filed followup bug 346208 for the script refocus issue (which I don't really understand, so the bug's kinda vague).

Comment 17

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 230065 [details] [diff] [review]
patch v1

>       case NS_MOUSE_EXIT_SYNTH:
>-      {
>         aVisitor.mEventStatus = nsEventStatus_eConsumeNoDefault;
>+      case NS_BLUR_CONTENT:
>         rv = LeaveLink(aVisitor.mPresContext);
>-      }
>       break;

I really dislike fallthroughs in switch statements, especially in non-trivial code like this. The chance of bugs in the future when someone changes this code is very big. Please just duplicate the assignment and use proper breaks.

sr=sicking with that.

Comment 18

[Peter Kasting]

Fixed on trunk with the change from comment 17.

mozilla/content/html/content/src/nsGenericHTMLElement.cpp 1.665