Closed Bug 418323 Opened 17 years ago Closed 17 years ago

Find bar: tab chain stuck on forward button (10.5), close button not in tab chain (10.4)

Categories

(Camino Graveyard :: Toolbars & Menus, defect)

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

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: phiw2, Unassigned)

References

Details

(Keywords: regression)

STR 1. command F 2. type word, search begins 3. tab key to go to one of the buttons. 4. Get stuck on the 'next' button. No way forward or backward anymore. 2.0a1pre (1.9b4pre 2008021816) Tested on 10.5.2 regressed from bug 408530.
On 10.4, that seems to work fine, although the close button is out of the loop again (that was fixed in bug 408536). Not sure if this is related to the same checkin, I don't often have access to 10.4 these days.
Blocks: 408530
Weird; this definitely worked when I tested the nibs. On branch, the 10.5 nib is fine, and things should be identical :/
Flags: camino1.6b3+
Keywords: regression
Target Milestone: --- → Camino1.6
Nib inspection reveals that the key loops are set up properly in both nibs. Let me go check the branch nib on 10.3.9....
Branch nib on 10.3.9 appears OK, too, so this seems trunk-only; re-twiddling flags appropriately. I realized looking at bug 408530 again that I never tested with the follow-on patch; perhaps that's what caused the loop to break on trunk?
Flags: camino1.6b3+ → camino1.6b3-
Summary: Find bar: tab chain stuck on forward button → Find bar: tab chain stuck on forward button (10.5), close button not in tab chain (10.4)
Target Milestone: Camino1.6 → ---
Version: unspecified → Trunk
It's the same nib and code on branch and trunk, and the case sensitivity patch would have no effect on tab behavior. Perhaps this is related to some of the event weirdness in Cocoa widgets (similar to esc being eaten by the content area rather than clearing URL autocomplete)?
(In reply to comment #5) > It's the same nib and code on branch and trunk, and the case sensitivity patch > would have no effect on tab behavior. Perhaps this is related to some of the > event weirdness in Cocoa widgets (similar to esc being eaten by the content > area rather than clearing URL autocomplete)? > Hmm. Are you saying that this bug is older, then ? I have the 20080215 build here, and tabbing seems to work. Gonna check when that patch that fixed the esc problem went in and out.
Oh, indeed; on 10.5, we get stuck on Next (or close, if you shift-tab) in 2008-02-12-00 (just the build I happened to have around; it may have broken before this). Gecko :/
Flags: blocking1.9?
CmTrunk 2008-02-10-01 works, 2008-02-11-00 fails Regression range: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=Camino&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-02-10+01%3A00&maxdate=2008-02-11+00%3A00&cvsroot=%2Fcvsroot It's almost certainly the backout of bug 358379 (aka the fix for bug 415923) that caused this (that's the only widget or camino checkin that seems at all possible to cause it).
Blocks: 358379
No longer blocks: 408530
Flags: tracking1.9? → blocking1.9?
Yesterday I started looking again at the browser window key view loop fixes I've been promising, and when doing so I noticed entirely new problems that didn't exist before. For one, I cannot even tab past the window's NSToolbar into the bookmark bar at all. Even after I manually allow a bookmark button to become the first responder, using F-Script, and set its nextKeyView outlet to an adjacent one, tabbing does not move focus. As far as the find bar is concerned, a quick look again using F-Script reveals that nextValidKeyView is in fact returning the "match case" button. I swore yesterday that Apple did something in Leopard, or perhaps just 10.5.2, that broke this behavior. Now, with more evidence, I'm really wondering what the deal is... I've noticed similar problems with the key view loop in other apps as well, such as CSSEdit, which had no problems on Tiger.
(In reply to comment #9) > and when doing so I noticed entirely new problems that didn't exist before. If you are on trunk, then it's very likely to be comment 8. Trunk is not a good place to do any work related to tab chain at the moment.
Can someone on 10.4 verify that the tab chain in the Find bar is working right for them in tomorrow's nightly (e.g., the one being built in just a few hours)? The 10.5 situation is fixed for me locally following the re-checkin of bug 358379.
On 10.5.2, the 'previous' [<] is not reachable in my test. All others work OK. (home made build). No idea about 10.4.
< is reachable by left-arrowing from >. That's apparently expected behavior for segmented controls.
(In reply to comment #13) Aha. Thansk for digging that up. In that case, the whole tab chain for the find bar works perfectly fine on 10.5.
Eiichi, can you grab the latest trunk build and make sure that all the controls in the Find bar, but specifically the close button, can be focused by tabbing when Full Keyboard Access is enabled (see comment 1)? We have a shortage of readily available 10.4 users, and we'd like to close out this bug if it is fixed on 10.4. Thanks!
(In reply to comment #15) > Eiichi, can you grab the latest trunk build and make sure that all the controls > in the Find bar, but specifically the close button, can be focused by tabbing > when Full Keyboard Access is enabled (see comment 1)? Smokey, I tested latest trunk (3/3/08) on 10.4 with Full Keyboard Access enabled. And I confirm that all the controls in the Find bar work fine.
Thanks Eiichi. This can be marked fixed then.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Many thanks, indeed! Clearing the blocking1.9? nomination since this is fixed following bug 358379.
Status: RESOLVED → VERIFIED
Flags: blocking1.9?
You need to log in before you can comment on or make changes to this bug.