Closed Bug 461981 Opened 16 years ago Closed 16 years ago

Keyboard navigation broken in feed preview page

Categories

(Firefox Graveyard :: RSS Discovery and Preview, defect, P2)

3.0 Branch

Tracking

(Not tracked)

RESOLVED FIXED
Firefox 3.6a1

People

(Reporter: aaronlev, Assigned: ddahl)

References

(Depends on 1 open bug)

Details

(4 keywords, Whiteboard: fixed by bug 399427)

Attachments

(1 file, 1 obsolete file)

Go to a site with a feed such as:
http://www.marcozehe.de

First problem -- how does a keyboard-only user view the feed? (This part may be a dupe from an old bug)

Click on the feed icon.

Second problem -- tab navigation is broken. The tab cycle only contains the XUL combobox in it, and nothing else. And the second round of tabbing through does not visit anything in the content at all.
Flags: blocking-firefox3.1?
I ran a few xul tests and it seems to be the menu popup that is breaking things. I added a dependency (bug 348830) since it might be related, and the test case on that example exhibits similar tab nav breakage on the second round of tabbing.
Depends on: 348830
(In reply to comment #0)
> Go to a site with a feed such as:
> http://www.marcozehe.de
> 
> First problem -- how does a keyboard-only user view the feed? (This part may be
> a dupe from an old bug)

There is a menu item "Subscribe to This Page" under Bookmarks.

If we want to put the URL bar icons in the tab order it should be straight forward. In browser/themes/pinstripe/browser/browser.css we could add a style to urlbar-icons like this:

 #urlbar-icons {
+  moz-user-focus: normal;
 
In browser/base/content/browser.xul we might want to that "-moz-user-focus: none" on the feed-button menu.
I think this is WONTFIX, actually.

Back when Mark Pilgrim was working on this stuff, he and I agreed that the Bookmarks menuItem was the best way to do accessible feed subscription stuff. Once you enter that UI, you don't get into the bit where you need to do tabbing.
Flags: blocking-firefox3.1? → blocking-firefox3.1-
I disagree. This was working perfectly in Firefox 3.0.x. E. G., you go to www.marcozehe.de, choose Bookmarks/Subscribe to this page, and could then navigate the upcoming page using the keyboard (e. g. select a different feed subscription application from the combobox). This is a Firefox 3.1 regression in keyboard navigation. Re-requesting blocking.
Flags: blocking-firefox3.1- → blocking-firefox3.1?
Ah, then what you're saying is that the first problem from comment 0 is not the issue here, it's the second.

Updating summary, --> RSS Discovery & Preview, asking for regression range.
Component: Keyboard Navigation → RSS Discovery and Preview
Flags: blocking-firefox3.1? → blocking-firefox3.1+
QA Contact: keyboard.navigation → rss.preview
Summary: Keyboard navigation broken for subscribing to feeds → Keyboard navigation broken in feed preview page
Target Milestone: --- → Firefox 3.1
Keywords: regression
Priority: -- → P2
Version: unspecified → Trunk
Version: Trunk → 3.0 Branch
The tab navigation issue looks like bug 399427. There was a hacky workaround posted in the xul newsgroup recently.
Depends on: 399427
Whiteboard: possible patch in bug 399427
(In reply to comment #7)
> The tab navigation issue looks like bug 399427. There was a hacky workaround
> posted in the xul newsgroup recently.
I looked at mozilla.dev.tech.xul and didn't see it.  It's possibly I wasn't looking close enough at all the posts though.  Care to point it out?
The workaround is to do:

function menulistFocused(menulist) {
  var range = document.createRange();
  range.selectNode(menulist);
  var selection = window.getSelection();
  selection.addRange(range);
  selection.collapseToStart();
}

<menulist onfocus="setTimeout(menulistFocused, 0, this)">
In fact, you could probably get by just using:

<menulist onfocus="setTimeout(function() getSelection().removeAllRanges(), 0)">
This (code from comment #10) appears to work, however you can only tab focus the menulist one time, as you tab through the rest of the content and back to the urlbar, you cannot tab back into the menulist. Any more ideas? This is still a bit voodoo to me:)
Assignee: nobody → ddahl
Now that I have read some of the back story on this bug via the "depends on" bugs, I am thinking you could fix this easily enough if the subscribe page is converted to a XUL window instead of XHTML. What is the rationale for using XHTML w/ XUL inside for this markup/window/functionality?
I don't want to open up a can of worms by questioning the XUL in XHTML display of the subscribe window, (yet:)) so after applying the proposed patch in comment 9, and testing on  Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090204 Minefield/3.2a1pre, it seems to work. cool.
Attached patch Proposed patch from comment 9 (obsolete) (deleted) — Splinter Review
Attachment #360597 - Flags: review?(mak77)
Comment on attachment 360597 [details] [diff] [review]
Proposed patch from comment 9

sorry, i'm not a valid peer to review this. sayrer is probably better (or can forward you to a valid peer for this component).
Attachment #360597 - Flags: review?(mak77) → review?(sayrer)
Attachment #360597 - Flags: review?(sayrer) → review?(mano)
https://bugzilla.mozilla.org/show_bug.cgi?id=399427#c30 

Perhaps when the above bug is fixed we will need to back out this change? (thanks Mak77)
Attachment #360597 - Flags: review?(mano) → review?(enndeakin)
Comment on attachment 360597 [details] [diff] [review]
Proposed patch from comment 9

>+  // Work around for menulist XUL in XHTML bug 461981
>+  menuListFocused: function SH_menulistFocused(menulist) {
>+    var range = document.createRange();
>+    range.selectNode(menulist);
>+    var selection = window.getSelection();
>+    selection.addRange(range);
>+    selection.collapseToStart();
>   }
>+
> };
>+
>+

Remove all these extra blank lines and this is ok.
Attachment #360597 - Flags: review?(enndeakin) → review+
Can we please land this on branch but not on trunk and leave this bug open in favor of bug 399427?
Attachment #360597 - Attachment is obsolete: true
Does this need approval from a module owner for "branch only" checkin?
Keywords: checkin-needed
No approval needed.
Bug 399427 is fixed now so this should be fixed
I'm going to back this out from 1.9.1 when bug 399427 lands there.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Whiteboard: possible patch in bug 399427 → fixed by bug 399427
Target Milestone: Firefox 3.1 → Firefox 3.2a1
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: