Closed Bug 1001077 Opened 11 years ago Closed 10 years ago

When tabbing to an readonly input element, the cursor/caret shows up in the previous editable input field

Categories

(Core :: General, defect)

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

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla34

People

(Reporter: tgj1970, Assigned: roc)

References

Details

(Keywords: regression)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:28.0) Gecko/20100101 Firefox/28.0 (Beta/Release) Build ID: 20140317233339 Steps to reproduce: With this code: <html><body> <input type="text" value="" name="txt1" /> <input type="text" value="x" name="txt2" readonly="readonly" /> <input type="text" value="" name="txt3" readonly="readonly" /> </body></html> When tabbing from "txt2" to "txt3" a cursor/caret appears in "txt1". Actual results: It seems like when tabbing into an empty readonly input element, then the (non-blinking)cursor appears in the previous focused(and non-readonly) input. Expected results: The non-blinking cursor/caret should appear in the actual focused input.
Tabbing back to "txt1" and then forward again will work as expected. Reload the form and tab to reproduce.
OS: Linux → All
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Version: 28 Branch → 19 Branch
Regression window(m-i) Good: http://hg.mozilla.org/integration/mozilla-inbound/rev/5741971493aa Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121028213337 Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/ed720383aab3 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121028213837 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=5741971493aa&tochange=ed720383aab3 Suspect: f31f3948e433 Robert O'Callahan — Bug 805697. There is no point in checking for the existence of a caret in the presshell --- it will always have one, and it wouldn't matter if it didn't. r=mats
Blocks: 805697
nsCaret is a mess. But basically what happens is that, after focusing the third <input>, all the selection and focus changes result in a deferred call to DrawCaret(true). We get to nsCaret::DrawAtPositionWithHint with mLastContent set to the first <input>, mVisible true and mDrawn false. We return early without setting mLastContent because userinterface->mUserModify == NS_STYLE_USER_MODIFY_READ_ONLY. Then we toggle mDrawn to true and exit. Later there's a paint and we call nsCaret::GetCaretFrame, which calls GetCaretFrameForNodeOffset on the old mLastContent etc (the first <input>), drawing the caret there.
My massive cleanup of nsCaret in bug 1048752 fixes this bug.
Depends on: 1048752
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Assignee: nobody → roc
Target Milestone: --- → mozilla34
Did a quick verification on Win 7 x64, with Firefox 34 Aurora (BuildID=20141013004002), using steps and test from comment 0, and while the behavior is not the same it still does not seem to work as intended: now, when tabbing from "txt2" to "txt3" the cursor/caret is no longer moved to "txt1", it's just not displayed at all... doing a full second pass with tab will display the non-blinking cursor/caret as expected (and same as before). Should this issue be reopened?
You need to log in before you can comment on or make changes to this bug.