76621 - sidebar elements should not grab focus from other parts of window

Status: VERIFIED FIXED

(SeaMonkey :: Sidebar, defect, P2)

Description

[Jesse Ruderman]

Steps to reproduce:
1. Open the sidebar
2. Select the Search panel
3. Right-click on a link in the main content area and select "open link in new 
window", or restart Mozilla.

Result: textbox in Search panel has focus (from bug 61417 being fixed).

Expected results: page has focus, but the textbox in Search panel has focus 
within the panel (so ctrl+tabbing to the sidebar panel would focus that 
textbox).

See also bug 50223, "Clicking on Sidebar tab should set focus to sidebar page 
or widget".

Comment 1

[Jesse Ruderman]

The Bookmarks and History panels now also steal focus from the page when they 
load.

Comment 2

[Jesse Ruderman]

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

Comment 3

[sairuh (rarely reading bugmail)]

nbaca, you've seen this before, yes? [methinks you had ask me about this
oh-so-long ago...]

Comment 4

[Ninoschka Baca]

Sorry, I don't recall.

Comment 5

[Jesse Ruderman]

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

Comment 6

[sairuh (rarely reading bugmail)]

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

Comment 7

[slice1900]

FYI, when I select open link in new window until I click in that window I don't
have keyboard focus there, even though it is topmost.  I thought the focus was
just gone, but I recently found it is in my disabled search sidebar (or at least
I certainly found it there when I opened it and then middle moused a link)  So
you don't even have to have the search sidebar opened and selected for it to
steal the focus apparently.  Hope this bit of info helps.

Comment 8

[Rob]

This is something that really annoys me. If I click on a quicklink (in Mozilla
browser), a long page (say) loads, but the focus for the keyboard seems to not
be the newly loaded page, but rather the quicklink bar. What a nuisance. I want
to scroll down with the arrow keys, but rather have to click in the page area,
then scroll with the arrow keys.

Comment 9

[Don Blaheta]

Yup, this one's a pain in the butt.  Note, by the way, that steps 1 and 2 of the
"steps to reproduce" aren't even necessary---this happens in any newly opened
window.

Comment 10

[Don Blaheta]

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

Comment 11

[Tim Powell]

Marking 4xp because the behavior of other browsers has been to give focus to the
content area of the window so that keyboard scrolling works immediately after
load. Sidebar elements gaining focus is especially confusing when the sidebar is
collapsed and tab key presses seem to go nowhere.

Comment 12

[slice1900]

Why does this not have a target milestone?  I'm amazed it has been around for so
long, this is the sort of stupid bug that should be trivial to fix that is
immediately noticed by regular users of other browsers and gives an initial
indication of low quality and difficulty of use.  I guess its too late to make
0.9.4, but can someone please mark this for 0.9.5?  Perhaps 'polish' belongs in
the keyword list as well.

This is the sort of thing that is IMHO a lot more noticeable to users than
letter of the law HTML compliance or a crasher that affects a minority of users
only once in a while.

Comment 13

[John Morrison]

-> trudelle for assignment/priority

Comment 14

[Peter Trudelle]

sidebar->sgehani

Comment 15

[Jesse Ruderman]

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

Comment 16

[Greg K.]

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

Comment 17

[Jon Califf]

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

Comment 18

[Christian Eyrich]

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

Comment 19

[R.K.Aa.]

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

Comment 20

[Jake]

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

Comment 21

[Ashley Bischoff (blog at handcoding.com)]

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

Comment 22

[Samir Gehani]

Moving to mozilla0.9.8.

Comment 23

[slice1900]

This sucks.  How hard can this be to fix?  I'd rather use a Mozilla that has one
more unfixed topcrasher and this fixed than the other way around.  I'll bet I'm
not the only one who thinks this is the #1 most annoying bug in Mozilla.  But
because it doesn't cause a crash its priority will always be too low -- it'll
always get triaged off to the next milestone.  At this rate, I wouldn't be
surprised to see a 1.0 release with this bug outstanding.  Shouldn't a bug that
will likely cause at least a few people to get so annoyed with Mozilla/Netscape
they go back to IE and never give it another chance be a high priority also?

The number of duplicates filed on this bug ought to serve as a clue to people
how annoying this is.  If it weren't for talkback, how many people would bother
to report the occasional crasher?  This "noncritical" bug must be seen as pretty
bad for so many people to have independantly reported it.

If only there were some way to completely disable the stupid sidebar instead of
just hiding it.  I certainly hope this bug isn't suffering due to new features
being added for the sidebar.

Comment 24

[Jon Califf]

You can disable this behavior by going to the Sidebar |Tabs | Customize Sidebar,
and removing all sidebar items.

Comment 25

[Jesse Ruderman]

Part of the reason this bug has so many dups is that users weren't aware that 
it was the sidebar that had stolen focus, so they didn't know to search 
for "sidebar".

You can disable the sidebar: View > Sidebar (F9).  However, many users, even 
users who know that the focus problem involves the sidebar, aren't aware that 
the sidebar can be disabled.

Comment 26

[Jesse Ruderman]

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

Comment 27

[Samir Gehani]

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

Comment 28

[Matthew T (active 1999-2002)]

slice1900, if you're fixing this bug yourself, or paying someone to do so, you
can set it to any target milestone you like. But bugs don't fix themselves, and
using Bugzilla as a forum for whining just slows down everyone else.

Comment 29

[Samir Gehani]

The original bug as reported no longer occurs in a 2001-11-29-03-trunk mozilla
trunk build.  Maybe bryner's recent focus changes fixed this?  Is that the case,
bryner?

Comment 30

[sujay]

verified.

Comment 31

[Jesse Ruderman]

I can still reproduce this bug as I reported it, using 2002 012008 on Win98.  
Reopening.

Comment 32

[Samir Gehani]

Sidebar/search triage team: nsbeta1+

Comment 33

[Peter Trudelle]

Reassigning 'several bugs at once' to Steve Morse, to level the load better
across the team.

Comment 34

[Samir Gehani]

Works for me again in 2002-04-16-17 (commercial 1.0 branch build).

Comment 35

[Martin Macok]

When I open "new window", the focus is on the sidebar, not content area (so I
cannot scroll the document with Page Down/Up, the bookmarks sidebar is scrolled
instead).

I'm using 20020417 build of moz1.0.0 branch on Mandrake 8.2 Linux.

Comment 36

[sujay]

verified.

Comment 37

[Martin Macok]

When I open URL in new window (rightclick personal toolbar || rightclick sidebar
bookmark || rightclick A HREF in content area) the new window is created and URL
loaded - but the bookmark sidebar has always focus so PG_DOWN/PG_UP scrolls
bookmark sidebar instead of content area.

branch 20020418 on Mandrake 8.2 Linux.

Reopen? New bug?

Comment 38

[石庭豐 (Seak, Teng-Fong)]

 I'm using 20020418 and the bug isn't fixed.  My test is simpler:
(Make sure bookmark is selected on the sidebar.)  Open Mailer and close all
Navigator windows if there's any.  From within Mailer press Ctrl+N.
See that the cursor isn't on the address bar!
We should reopen this bug if it isn't fixed in another week.

Comment 39

[Brian Ryner (not reading)]

Are you sure it's the sidebar that has focus and not the page content?

Comment 40

[John Morrison]

For the originally reported 'steps to reproduce', and for the steps noted in
comment #38:
  -> current win2k trunk: focus is set in the content area; subsequent up/down 
     arrow or page will scroll the html page.
  -> current linux trunk and 4/21 branch build: focus is set in the textbox 
    (for search) or bookmarks tree (for bookmarks); subsequent keystrokes 
     go to the sidebar panel. This is with either focus-follows-mouse, or
     click-to-focus-window.

Reopending.

Comment 41

[scottputterman]

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email [e-mail].  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.

Comment 42

[scottputterman]

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email [e-mail].  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.

Comment 43

[Peter Trudelle]

Nav triage team needs info: Aaron- could you please comment on the reason you
apparently think  this should be nsbeta1+/adt2, and also on whether you think it
would be acceptable to fix this for RTM rather than beta.

Comment 44

[marlon bishop]

does this bug include the case where i hit "ctrl+n" and immediately begin typing
a url: the "ww" portion goes into the url bar, and the, "w.netscape.com/sports"
goes into search sidebar?

if so this is absolutely hidiculous

Comment 45

[Aaron Leventhal]

Any time the focus suddenly changes without being directed by the user, it's a
massive problem for screen reader users. Imagine you're having a document or
part of the UI read to you, and suddenly it's interrupted by some other speech
stream. You don't have any visual cues to show you what happened or why, and you
know have to go back and find your lost place. If this happens continuously as
it does with the sidebar, it's a major annoyance. This is quite similar to the
problems that popups cause for blind users.

Also, it's not just a matter of the output stream being interrupted. The case
that Marlon points out with typing in a URL is another facet to the same
problem, that all users experience.

Comment 46

[Peter Trudelle]

The case Marlon describes should not be happening at all, except if new windows
are set to load a blank page.  On New Window, focus should go to loaded content.

Comment 47

[Dave]

2002042412/Linux

I have prefs set to load home page on ctrl+n. If I do this and begin scrolling
with down arrow, I end up scrolling through my bookmarks sidebar and have to
click on the page to give it focus.

Comment 48

[marlon bishop]

the case i describe happens when i have blank page set for new windows.  focus
jumps from url to search sidebar.

Comment 49

[Peter Trudelle]

nsbeta1+

Comment 50

[Peter Trudelle]

->bryner

Comment 51

[Brian Ryner (not reading)]

Talked with saari and samir about this.  It appears that what we'll need is a
mechanism for the sidebar panels to only focus themselves on load if they were
activated by switching to the tab (as opposed to loading because a new window
was opened).

Comment 52

[Brian Ryner (not reading)]

Attachment: patch

This patch makes it so we only focus the sidebar panel if the user explicitly
selected it.  We will not focus the sidebar when a new window opens.

Comment 53

[Brian Ryner (not reading)]

Attachment: patch #2

change elementtofocus to a lowercase attribute, also fix up history-panel.xul.

Comment 54

[jag (Peter Annema)]

Comment on attachment 85384 [details] [diff] [review]
patch #2

sr=jag

Comment 55

[Blake Ross]

Comment on attachment 85384 [details] [diff] [review]
patch #2

r=blake
best patch I've seen in years.

Comment 56

[Brian Ryner (not reading)]

Checked in on the trunk, nominating for branch checkin for 1.0.1.

Comment 57

[sujay]

verified in 5/29 trunk build.

Comment 58

[Judson Valeski]

please checkin to the 1.0.1 branch after this has baked successfully on the
trunk until Friday, 05/31/02.

Comment 59

[石庭豐 (Seak, Teng-Fong)]

On the Roadmap, there's no indication when 1.0 will take place.  Do you think
there's not enough time for this to go in 1.0?

Comment 60

[R.K.Aa.]

i think this may have fixed bug 140009, bug 107966, bug 140797 
(remaining weirdness in bug 146619 / bug 128322)

Comment 61

[Jaime Rodriguez, Jr.]

adt1.0.1+ (on behalf ADT's behalf) for checkin to the 1.0 branch, pending
Driver's approval. Pls check this in asap.

Comment 62

[Brian Ryner (not reading)]

checked into the 1.0 branch.

Comment 63

[sujay]

verified in 6/4 branch build.

Comment 64

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1527381