214115 - [FIXr]Selection sticks when tabbing through textboxes

Status: RESOLVED FIXED

(Core :: DOM: Selection, defect, P1)

Description

[Boris Zbarsky [:bzbarsky]]

BUG PRESENT IN: 2003-07-01 07:00:00 and later builds
BUG NOT PRESENT IN: 2003-06-30 05:00:00 and earlier builds

STEPS TO REPRODUCE:
1) Load http://google.com
2) Type "abc" in the textbox
3) Hit tab
4) Hit "shift-tab" twice

EXPECTED RESULTS: focus on link before textbox, "abc" not selected

ACTUAL RESULTS: focus on link before textbox, "abc" selected

This happens on all pages I've tried with text inputs (including this bug page).

Assigning to brade based on the regression window and the files that were
touched in that window (the cleanup checkins look like the most likely culprit).

This makes keyboard navigation on Linux incredibly confusing, since it keeps
looking like you've clobbered your PRIMARY clipboard.

Comment 1

[Bill Mason]

Wondering how this can be a platform/os all/all bug when I can't reproduce it
2003072104 PC/WinXP using the steps given.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Because timeless reproduced it on Win98 with the steps given.

Sorry I forgot to mention that I was testing on Linux, as usual.

Comment 3

[Jason Bassford]

Also WFM.  7/27-04, XP.

Comment 4

[Kathleen :Brade]

Here's the bonsai query link for my checkins during that timeframe (for future
reference):
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=brade%25netscape.com&whotype=match&sortby=Date&hours=2&date=explicit&mindate=06%2F30%2F2003+05%3A00%3A00&maxdate=07%2F01%2F2003+07%3A00%3A00&cvsroot=%2Fcvsroot

Here's the bonsai query link for all checkins during the relevant timeframe:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=06%2F30%2F2003+05%3A00%3A00&maxdate=07%2F01%2F2003+07%3A00%3A00&cvsroot=%2Fcvsroot

I'd guess this regression is based on a specific pref; any clue/hint what pref?
Hmmmmm... maybe it's not pref-based.  I see it on my Mac when I do these steps:
 1) load a bug
 2) tab from QA Contact to URL to Summary to Status Whiteboard to Keywords
 3) notice that any fields which had text in them remain hilited when they shouldn't
 4) scroll down
 5) scroll up
 6) notice that the text fields are now correctly rendered

This is a layout / updating problem.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Could be the pref to select all text in a textbox when tabbing into it?   I have
it set to true; no idea what Bill and Jason have it set to.

Comment 6

[Boris Zbarsky [:bzbarsky]]

What handles triggering the repaint when the selection is added/removed?  The
only checkin I see offhand in that range that could cause things to not update
sometimes is for bug 158713, and that would only affect changes to actual style
declarations...

Comment 7

[Boris Zbarsky [:bzbarsky]]

*** Bug 213354 has been marked as a duplicate of this bug. ***

Comment 8

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch

This was caused by deCOMtamination, as dbaron mentioned in bug 213354.	roc
changed the test to actually test what it thought it was testing, and this
broke things because nsTypedSelection depends on this method to repaint even if
the selection state has not changed (because the selection display value could
have changed).

This patch just removes the check altogether (along with removing a never-used
boolean).

Comment 9

[Boris Zbarsky [:bzbarsky]]

Taking....

Comment 10

[Boris Zbarsky [:bzbarsky]]

Checked this in, mid-day on the 28th, pacific time.

Comment 11

[Boris Zbarsky [:bzbarsky]]

This should have been marked fixed...

Comment 12

[Jesse Ruderman]

*** Bug 215106 has been marked as a duplicate of this bug. ***