Happens with Mozilla 0.9.9 1. Open some page 2. Right click on page and select "Page Info" 3. Press CTRL+TAB several times to cycle panels (enjoy the feeling ;) 4. Upon reaching "Security", tabbing forwards and backwards (CTRL+SHIFT+TAB) stops. 5. Click on some other tab and tabbing shortcut works. Perhaps it is related to the fact that Security tab is made with an overlay?
confirmed on Win2k / 2002031104
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 98 → All
Hardware: PC → All
-> psm client library
Component: Page Info → Client Library
Product: Browser → PSM
Version: other → 1.01
Works for me with the 3/21 Win2000 trunk build.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
Reopening. I see this with the 3/25 Win2000 trunk build.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
-> browser, keyboard navigation
Assignee: db48x → aaronl
Status: REOPENED → NEW
Component: Client Library → Keyboard Navigation
Product: PSM → Browser
QA Contact: pmac → sairuh
Summary: Tabbing shortcut is broken in Page Info → Ctrl+Tab in Page Info fails if Help button has focus
Version: 1.01 → other
Who was this assigned to before on the security team?
Assignee: aaronl → rginda
Component: Keyboard Navigation → ChatZilla
QA Contact: sairuh → samuel
Bryner, focus issues.
Assignee: rginda → bryner
Why is this assigned to chatzilla?
dunno, but arron did it.
Component: ChatZilla → Keyboard Navigation
it is strange: If u open "Page Info" while in a security page, then "Page Info" tab will have some extra xul-widget and Ctrl-Tab works WELL!! So I think there would be something wrong with the PageInfoOverlay.xul about the event handler.
it is something wrong with event handling. when in security tab, the tabbox handler (http://lxr.mozilla.org/seamonkey/source/xpfe/global/resources/content/bindings/ tabbox.xml#115) can not be triggered at all.
When in the securityTab for a normal html page, the tab can not get focus because no xul-widget of that tab is focusable. Then the help button get the focus. But help button is not part of tabbox, so ctrl-tab key press are only bubbled to the main-window. see the following: 170,nsXULElement HandleDOMEvent debug info nodename=button id= classname= nsXULElement HandleDOMEvent debug info==end 171,nsXULElement HandleDOMEvent debug info nodename=box id= classname= nsXULElement HandleDOMEvent debug info==end 172,nsXULElement HandleDOMEvent debug info nodename=window id=main-window classname=dialog nsXULElement HandleDOMEvent debug info==end 173,nsXULElement HandleDOMEvent debug info nodename=box id= classname= nsXULElement HandleDOMEvent debug info==end 174,nsXULElement HandleDOMEvent debug info nodename=window id=main-window classname=dialog nsXULElement HandleDOMEvent debug info==end That is why ctrl-tab does not work for this securityTab. So I think we have to make that tab focusabel. The most rational way is to make the xul-widget tab focusable. I make a patch and it works.
could i own this bug?
Assignee: bryner → gilbert.fang
Created attachment 93692 [details] [diff] [review] make the xul-widget tab focusable hi, bryner and aaronl, what is your suggestion about the patch?
Anyway, when mozilla switch into the securityTab, the focus is always got by help button and user have to do one ctrl-tab to move focus to securityTab then ctrl-tab to the next tab. should we file a new bug on focus issue?
Great debugging, Gilbert. Aha, so this is another example of the problem in bug 129808. I think there is a more general fix, for all of these problems where there are multiple iframes in a dialog. If keystrokes are not handled by one of the iframe's/nsEventStateManger's, they should be offered to other visible iframes/nsEventStateManager's within the same tree for that dialog.
So, this will also make the tabbox part of the tabbing order, correct? I'm not sure I like that because there won't be any visual indication that the focus is there.
As far as I can see it's either that or put the help button inside the tabs, but then we'd have to have a copy on each panel. Actually though, now that I think about it some more, we could catch those events at the window node, and pass them to the tabbox if they match certain keycodes. I'd rather not do that though, because then what happens if those keys are ever redefined? You would be hitting one set of keys to change tabs, then hit the security tab and have to hit a different set. That would be annoying. Then there's always the drastic solution: we could just add a focusable element to the security tab itself :) On the other hand, there's a bug out there asking for the help button to be removed altogether, which would make the issue moot, for page info at least.
My patch for bug 114170 makes it possible to Ctrl+Tab when the Help button has focus.
This is a section 508 accessibilty bug, we don't want focus getting stuck.
Ok, here's my $.2 cents Visit https://www.verisign.com/ and follow the steps of the reporter. So it works for encrypted pages. Why? Because of the extra button! PageInfo should have a OK/CLOSE button, like all other managers and the preference windows. They all have OK/CLOSE buttons, and so should PageInfo. The extra button will fix this bug, it's moot when 'someone' add the stupid OK/CLOSE button. Again, just my $.2 cents.
that only works because the extra button is inside the tab. the button isnt handling the event, but because the even is starting at the focus and bubbling outward, it hits the <tabbox>, where it is handled. adding a ok/close buttons outside the tab wouldn't do anything.
My patch for bug 175893 fixes this too.
Am I wrong in thinking that bug 185772 is a DUPLICATE of this bug?
*** Bug 185772 has been marked as a duplicate of this bug. ***
*** Bug 250075 has been marked as a duplicate of this bug. ***
Summary: Ctrl+Tab in Page Info fails if Help button has focus → Ctrl+Tab in Page Info fails when Security tab is selected
This was fixed by checkin to bug 175893.
Status: NEW → RESOLVED
Last Resolved: 17 years ago → 14 years ago
Resolution: --- → FIXED
*** Bug 256237 has been marked as a duplicate of this bug. ***
*** Bug 270354 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.