Closed Bug 544146 Opened 15 years ago Closed 15 years ago

[Caret browsing]Hitting SPACE causes to set-focus/fire-submit　to last element that can have focus

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Tracking Flags:
Tracking Status
blocking1.9.2 --- .7+
status1.9.2 --- .7-fixed
status1.9.1 --- unaffected

People

(Reporter: masa141421356, Assigned: enndeakin)

References

Details

(Keywords: access, regression, useless-UI)

Attachments

(3 files)

testcase
(deleted), text/html
Details
testcase2
(deleted), text/html
Details
fix
(deleted), patch
smaug
: review+
dveditz
: approval1.9.2.7+
Details | Diff | Splinter Review
Attached file testcase (deleted) —
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2) Gecko/20100115 Firefox/3.6 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20100202 Minefield/3.7a1pre At caret browsing mode, when page loading finished, last element that can have focus already have focus without focus ring. If focuesd element is submit button , hitting [SPACE] key causes form submit, not page scrolling. Steps to reproduce: 1.Start Caret browsing mode 2.show testcase in same tab. 3.hit space Order of steps is very important. When entering caret browsing after page load, problem is not reproduced. Expected result: All links should not get focus. Acutual result: Link at bottom gets focus (background-color will be red)
Attached file testcase2 (deleted) —
When last element is submit button , hitting SPACE causes to submit form.
blocking1.9.2: --- → ?
Keywords: access, useless-UI
Summary: [Caret browsing]Hitting SPACE causes to set-focus and hit-space to last element that can have focus → [Caret browsing]Hitting SPACE causes to set-focus/submit　to last element that can have focus
Summary: [Caret browsing]Hitting SPACE causes to set-focus/submit　to last element that can have focus → [Caret browsing]Hitting SPACE causes to set-focus/fire-submit　to last element that can have focus
I found this problem at Japanese user's forum. According to original report, this problem is not reproduced at Fx3.5.7
Keywords: regression
I can reproduce with recent trunk/Linux.
OS: Windows XP → All
blocking2.0: --- → ?
Not reproduced: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090610 Minefield/3.6a1pre http://hg.mozilla.org/mozilla-central/rev/90d3e6d2cbb9 Reproduced: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090611 Minefield/3.6a1pre http://hg.mozilla.org/mozilla-central/rev/4430cae50dad
Attached patch fix (deleted) — — Splinter Review
This patch: - changes the direction to always be forward for focusing-to-caret mode - when the caret is not set at any location, or is at the root, don't call GetFocusInSelection but return early so that we don't continue looking for a node to focus.
Assignee: nobody → enndeakin
Status: NEW → ASSIGNED
This needs to be fixed on branch; accidental form submissions are pretty bad.
blocking1.9.2: ? → needed
Attachment #425494 - Flags: review?(Olli.Pettay)
Attachment #425494 - Flags: review?(Olli.Pettay) → review+
http://hg.mozilla.org/mozilla-central/rev/f353b4ec86ff
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
-->VERIFIED Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a2pre) Gecko/20100224 Minefield/3.7a2pre
Status: RESOLVED → VERIFIED
Can we land patch to Branch ?
This was marked blocking1.9.2:needed in February but nothing much happened. Seems like it ought to be blocking, renom-ing to see if that's still the right state or if maybe there's some missing prerequisite for a branch landing.
Blocks: 178324
blocking1.9.2: needed → ?
status1.9.1: --- → unaffected
status1.9.2: --- → wanted
blocking1.9.2: ? → .5+
blocking1.9.2: .5+ → .6+
Attachment #425494 - Flags: approval1.9.2.6?
Comment on attachment 425494 [details] [diff] [review] fix Approved for 1.9.2.6, a=dveditz for release-drivers
Attachment #425494 - Flags: approval1.9.2.6? → approval1.9.2.6+
blocking2.0: ? → ---
Depends on: 1442466
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: