Tabindex not working properly on XHTML Anchor testcase

RESOLVED WORKSFORME

Status

()

Core
Keyboard: Navigation
RESOLVED WORKSFORME
14 years ago
8 years ago

People

(Reporter: Philip K. Warren, Assigned: Pete Zha)

Tracking

Trunk
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

14 years ago
In the specified URL, the tabindex works properly the first time tabbing through
the elements, but the second time through, it seems to get confused and skip the
3rd and 5h links. The testcase works properly in IE (after saving the file with
a .html extension).

Expected behavior:
Tabbing goes from 3rd link -> 5th link -> 1st link -> 2nd link -> 4th link ->
url bar and back to the 3rd link.

Actual behavior:
Tabbing goes from 3rd link -> 5th link -> 1st link -> 2nd link -> 4th link ->
url bar and back to the 1st link, skipping 3rd and 5th links.

Comment 1

14 years ago
Created attachment 136161 [details] [diff] [review]
proposed patch

I think this bug was origianlly introduced by the fix of bug 130447
(http://bugzilla.mozilla.org/attachment.cgi?id=75086&action=view),  we should
not do that when the current selection is root content. See
http://lxr.mozilla.org/seamonkey/source/content/events/src/nsEventStateManager.cpp#3097

Comment 2

14 years ago
Comment on attachment 136161 [details] [diff] [review]
proposed patch

Aaron, what do you think?
Attachment #136161 - Flags: review?(aaronlev5)

Comment 3

14 years ago
Comment on attachment 136161 [details] [diff] [review]
proposed patch

r=aaronl
Attachment #136161 - Flags: review?(aaronleventhal) → review+

Comment 4

14 years ago
Comment on attachment 136161 [details] [diff] [review]
proposed patch

a=mkaply when you get an sr
Attachment #136161 - Flags: approval1.7+

Updated

14 years ago
Attachment #136161 - Flags: superreview?(bryner)

Updated

14 years ago
Assignee: aaronleventhal → kyle.yuan
Comment on attachment 136161 [details] [diff] [review]
proposed patch

After reading the DOM Range spec, it seems like this would break the case where
the selection start or end is between two immediate children of the root node. 
I don't think this can happen in legal HTML or XHTML, but it could presumably
happen in other markup languages.

I wonder if this is related to the testcase having a <p> node directly under
the <html> instead of under the <body>.

Comment 6

14 years ago
I saved the test case locally and found an interesting thing: if I changed the
file suffix to html, the bug will be gone; if I still use the .xml suffix, the
bug  is reproducible no matter where the <p> tag is (under <html> or under <body>).
Blocks: 226823
This is WFM on Gecko/20040302 Firefox on Debian, btw.
Comment on attachment 136161 [details] [diff] [review]
proposed patch

minusing, this doesn't seem right.
Attachment #136161 - Flags: superreview?(bryner) → superreview-

Updated

12 years ago
Assignee: yuanyi21 → pete.zha
Works fine in Firefox 20090721 nightly on Linux.  Probably fixed by the
new focus manager (bug 178324).
I'll resolve the bug WFM and push a regression test as soon as it clears
all platforms on TryServer.
Created attachment 390505 [details] [diff] [review]
mochitest3.diff
Created attachment 390665 [details] [diff] [review]
mochitest5.diff
Attachment #390505 - Attachment is obsolete: true
Pushed the test:
http://hg.mozilla.org/mozilla-central/rev/3c87acfd4ca4

-> WORKSFORME
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Flags: in-testsuite+
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.