Closed Bug 226361 Opened 21 years ago Closed 15 years ago

Tabindex not working properly on XHTML Anchor testcase

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: pkwarren, Assigned: zhayupeng)

References

(
URL
)

Details

Attachments

(2 files, 1 obsolete file)

proposed patch
1.23 KB, patch
aaronlev
: review+
bryner
: superreview-
mkaply
: approval1.7+
Details | Diff | Splinter Review
mochitest5.diff
4.70 KB, patch
Details | Diff | Splinter Review
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.
Attached patch proposed patch — — Splinter Review
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 on attachment 136161 [details] [diff] [review] proposed patch Aaron, what do you think?
Attachment #136161 - Flags: review?(aaronlev5)
Comment on attachment 136161 [details] [diff] [review] proposed patch r=aaronl
Attachment #136161 - Flags: review?(aaronleventhal) → review+
Comment on attachment 136161 [details] [diff] [review] proposed patch a=mkaply when you get an sr
Attachment #136161 - Flags: approval1.7+
Attachment #136161 - Flags: superreview?(bryner)
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>.
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>).
This is WFM on Gecko/20040302 Firefox on Debian, btw.
No longer blocks: badtests
URL: http://mozilla.org/quality/browser/st... → 1ldGEgbmFtZT0iZ2VuZXJhdG9yIg0KDQpjb25...
Comment on attachment 136161 [details] [diff] [review] proposed patch minusing, this doesn't seem right.
Attachment #136161 - Flags: superreview?(bryner) → superreview-
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.
Attached patch mochitest3.diff (obsolete) — — Splinter Review
Attached patch mochitest5.diff — — Splinter Review
Attachment #390505 - Attachment is obsolete: true
Pushed the test: http://hg.mozilla.org/mozilla-central/rev/3c87acfd4ca4 -> WORKSFORME
Status: NEW → RESOLVED
Closed: 15 years ago
Flags: in-testsuite+
Resolution: --- → WORKSFORME
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: