Closed Bug 352582 Opened 18 years ago Closed 16 years ago

leftmost toolbar buttons acquire keyboard focus at odd moments

Categories

(Camino Graveyard :: Toolbars & Menus, defect)

Product:
Camino Graveyard
Component:
Toolbars & Menus
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Camino2.0

People

(Reporter: bdeb, Assigned: murph)

References

Details

(Keywords: regression)

User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; chrome://navigator/locale/navigator.properties; rv:1.9a1) Gecko/20060912 Camino/1.2+ Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; chrome://navigator/locale/navigator.properties; rv:1.9a1) Gecko/20060912 Camino/1.2+ The back and forward buttons acquire gray halos when used Reproducible: Always Steps to Reproduce: 1. Open several tabs, each with several sites in its history 2. Select the leftmost tab 3. Select the next tab along 4. Click 'back'. The tab goes back one page (good). 5. If the back button is still available, it has a gray halo. If it is now grayed out, the forward button now has a gray halo 6. Click the next tab along. 7. The anomalous highlight goes away 8. Click back. The highlight comes back Notice: This doesn't happen when using the leftmost tab! That seems to work fine.
The "highlight" is almost certainly the full keyboard access focus (you can confirm this by going to System Preferences->Appearance and changing appearance to "Blue", then seeing if the grey highlight turns blue). I can't repro this (with or without FKA). Do you have FKA on? You can check by going to System Preferences->Keyboard and Mouse->Keyboard Shortcuts and seeing whether the "Full Keyboard Access" pref is set to "Text boxes and lists only" or "All controls".
You're right, this only happens with Full Keyboard Access enabled for 'All controls'. It is indeed the keyboard focus highlight. So I guess the bug here is that the forward/back buttons acquire focus under a combination of circumstances that I can't divine. [And perhaps also that the focus highlight looks like a mistake in the graphite colour scheme.]
Summary: back and forward buttons acquire strange highlights → back and forward buttons acquire keyboard focus at odd moments
Any luck yet figuring out when/why they get focus unexpectedly?
If you're asking for better steps to reprdouce, I can't give any -- the instructions I gave show the bug >50% of the time for me. I can tell you that the focus works correctly (i.e. like 1.0.3 etc) in version 2006052204 (1.2+) and is broken in 2006052422 (1.2+).
Håkan, can you repro this at all? Do you see anything in that regression window that looks likely to be a cause of this?
URL: any
Keywords: regression
I've seen this, but I thought that was just my extremely hacked trunk build. IIRC, I've only seen it in a debug build, and not in any nightly I've downloaded.
*** Bug 359476 has been marked as a duplicate of this bug. ***
Confirming, since there's been a dupe filed. Even if we don't know how to repro this, it's clear it's happening somehow (and a dev has seen it).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → Camino1.2
This bug is not hard to reproduce; it just seems to be timing-specific. I triggered it about once a minute while randomly opening tabs and loading pages. It's not necessary to go back for this to happen; sometimes the focus changes when a page is loaded for the first time. Focus also may change while a page is loading, and revert when it's finished. Like the original poster I have never been able to reproduce this in a window which has never had any tabs in it; however, I have triggered it in a window which once had tabs in it, but now only has a single page displayed.
I've never gotten the issue exactly as described here (or in the dupe) but I'm seeing a lot of pages losing focus to the location bar lately. Probably the same issue (don't have FKA on here either). Has anyone seen this on branch builds, particularly 1.1a1+ stuff? If so, this really ought to block 1.1. It's horribly annoying. cl
I've been seeing this recently (also on trunk). For me it's specifically the leftmost toolbar button (which isn't necessarily back/forward), which means that this seems very similar to bug 185385.
Summary: back and forward buttons acquire keyboard focus at odd moments → leftmost toolbar buttons acquire keyboard focus at odd moments
*** Bug 360311 has been marked as a duplicate of this bug. ***
Since this seems to be trunk-only, setting the right target and version. If anyone can repro these on the branch, please let us know.
Target Milestone: Camino1.2 → Camino2.0
Version: unspecified → Trunk
Here's a partial stack from reproducing it (with a tiny bit of instrumentation): #0 -[ToolbarButton becomeFirstResponder] (self=0x269e8f0, _cmd=0x90a92ed0) at /mozilla/camino_trunk/mozilla/camino/src/browser/BrowserWindowController.mm:503 #1 0x933ed783 in -[NSWindow makeFirstResponder:] () #2 0x000523c1 in -[BrowserWindow makeFirstResponder:] (self=0x2699890, _cmd=0x90aacaa8, responder=0x269e8f0) at /mozilla/camino_trunk/mozilla/camino/src/browser/BrowserWindow.mm:66 #3 0x933cbaee in -[NSView _setHidden:] () #4 0x2ee4d042 in nsChildView::Show (this=0x30e97730, aState=0) at nsChildView.mm:717 #5 0x16e198bf in DocumentViewerImpl::Hide (this=0x30ec21f0) at nsDocumentViewer.cpp:2034 #6 0x16e17f9a in DocumentViewerImpl::Destroy (this=0x30ec21f0) at nsDocumentViewer.cpp:1522 #7 0x16e18f3c in DocumentViewerImpl::Show (this=0x30e4f150) at nsDocumentViewer.cpp:1902 #8 0x16e293cb in nsPresContext::EnsureVisible (this=0x3837d490, aUnsuppressFocus=0) at nsPresContext.cpp:1357 #9 0x16e393cc in PresShell::UnsuppressAndInvalidate (this=0x2b36800) at nsPresShell.cpp:4864 #10 0x16e39688 in PresShell::UnsuppressPainting (this=0x2b36800) at nsPresShell.cpp:4912 #11 0x16e15f71 in DocumentViewerImpl::LoadComplete (this=0x30e4f150, aStatus=0) at nsDocumentViewer.cpp:1101 #12 0x2db281b1 in nsDocShell::EndPageLoad (this=0x26ad220, aProgress=0x26ad234, aChannel=0x34928750, aStatus=0) at nsDocShell.cpp:4739 We should probably look into whether that's the right way for us to act on a makeFirstResponder:, but it's also worth figuring out on the core side whether it makes sense that we get that call on pageload at all.
It looks like it makes sense; a view is hidden, so the window is told to move the focus, and for some reason (this is the bug) it decides that the ToolbarButton looks like a good choice. I wonder if our custom button cells in the back/forward toolbar buttons accept first responder or something like that.
(In reply to comment #15) > It looks like it makes sense; a view is hidden, so the window is told to move > the focus, and for some reason (this is the bug) it decides that the > ToolbarButton looks like a good choice. Why is a view hidden? Why is anything besides the content area even allowed to take the focus in this case? Focus moving out of the content area on pageload is universally bad, I think. cl
also happening here. i'd give a diff regression window though, since this was NOT happening for me as late as 2006101402 (1.2+). I also think i have a 100% steps to rep. here. 1 - make sure new tabs are loaded in background by default 2 - open a page with lots of links on it (for example, this one). then open those links in tabs. 3 - now, switch to one of the new tabs and click on any link in that tab if the page you navigate to after (3) does not set the focus upon loading to some text field, the first available non-disabled toolbar item should be highlighted. hope this helps...any progress on this so far?
in my testing, this works fine with Version 2006110206 (1.2+) and breaks on Version 2006110302 (1.2+). note that this is extremely obnoxious because it prevents any keystrokes that would normally work with the page active from working. as an example, hitting "backspace" with the focus on a toolbar does nothing. hitting spacebar will activate the toolbar button, as mentioned. also, any accessibility keys defined in the page (for example, hitting ctrl-e to edit a page on Wikipedia) do not work.
Regression range for Paul's comment: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&date=explicit&mindate=2006-11-02&maxdate=2006-11-04 Regression range for Ben's comment: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&date=explicit&mindate=2006-05-23&maxdate=2006-05-25 The fix for bug 106695 looks like a possible candidate, but that's sort of a half-educated guess.
This looks a lot like a dupe of bug 185385 to me. In other words, we seem to have had this problem in various incarnations before, as far back as 2002. cl
This is definitely not a precise dupe, i.e. the symptoms I observed are not the same as those described in bug 185385. But it also seems that the symptoms reported by Paul Borokhov with recent trunk builds are not identical to the ones I see with older builds (also, the first build that Paul sees the bug in is from after I originally filed the bug). Each in a slightly different way, these seem to be manifestations of a wider bug, 'Focus should be assigned to the content view when each page finishes loading' or similar.
here's something weird: i downloaded the same build i'm currently using, Version 2006110206 (1.2+), to my mom's brand new 17-inch iMac. it was exhibiting this bug. now i'm using the exact same version on a powerbook g4 which doesn't exhibit the bug. i didn't get a chance to do a full regression check to see in which version the problem disappeared on my mom's computer, but it seems weird nonetheless that i'm getting different results on different hardware.
this is still broken with the latest trunk build but works OK (i.e. toolbar does NOT steal focus) on the 1.1a2+ builds.
This bug is still open and set to "Trunk", so in absence of being closed or a report that it's suddenly broken on the branch, there's no need to continue to confirm its existence.
(In reply to comment #18) > in my testing, this works fine with Version 2006110206 (1.2+) and breaks on > Version 2006110302 (1.2+). Maybe there are two bugs. I'm seeing this latter regression range for a very similar bug in Firefox. However, in the case of Firefox, the "Full Keyboard Access" pref seems to be irrelevant, the bug occurs no matter what it's set to. I've filed a separate bug for Firefox (bug 383579), which has some steps that reproduce it 100% of the time, and also notes some other symptoms. It might be worth seeing if the Camino bug can be reproduced the same way.
Does anyone still still see this issue ? It stopped happening here around the time when Gecko Trunk switched to use gcc4.01/10.4uSDK for PPC builds.
(In reply to comment #26) > Does anyone still still see this issue ? > It stopped happening here around the time when Gecko Trunk switched to use > gcc4.01/10.4uSDK for PPC builds. That would fit the relationship with Firefox bug 383579, which is also only reproducible in gcc 3.3 builds, and only when libxul is disabled as well. So while the underlying bug probably isn't fixed, but the symptoms are hidden.
Except this bug was originally reported by people on Intel, which was already using 10.4u/gcc4....
(In reply to comment #28) > Except this bug was originally reported by people on Intel, which was already > using 10.4u/gcc4.... > I said 'around the time PPC builds switched...'. Iirc, a couple of other Camino bugs landed in that time frame. But I haven't had time to check it out, yet.
So, 6 months later, has anyone still been seeing this?
Simple steps to reproduce on 10.4. (I didn't test on 10.5.) 1. Set "Full Keyboard Access" pref to "All controls". 2. Open "Camino. Mozilla Power, Mac Style" http://caminobrowser.org/. 3. Open a new tab for the "Features" link on the page. 4. Close the tab "Camino. Features". 5. Open the "Features" link. 6. Back button is focused. 7. Go back to "Camino. Mozilla Power, Mac Style". 8. Reload button is focused.
Please retest this in tomorrow (2008-09-20) Cm2-M1.9 nightly builds (especially on 10.4), since bug 152987 and friends have overhauled our keyboard loop.
I confirmed that this bug has been fixed with my own build on 10.4. And I'll test this in official nightly builds (2008-09-20) Cm2-M1.9.
I retested this in official nightly builds (2008-09-20) Cm2-M1.9, and I confirmed that this bug has been fixed on 10.4.11.
I hadn't seen this issue for ages. The latest round of patches (comment 32) did not cause any problems here (10.5.5/Intel).
Since Eiichi saw this as recently as May (comment 31) and doesn't see it any more (comment 33/34), FIXED by bug 152987 and friends.
Assignee: nobody → murph
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.