637671 - Highlighting broken with subselect and hiding/showing dom elements

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect)

Description

[Lothsahn]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12) Gecko/20100101 Firefox/4.0b12
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12) Gecko/20100101 Firefox/4.0b12

We are seeing that text fields are remaining highlighted when they have even been highlighted in the past.

This causes rendering issues where fields that should not be highlighted are.  This is a regression from FF3, and no other browsers show this behavior (Safari, Chrome, IE).

See the steps to reproduce and attached reduction for more information.  The reduction is the same page available at:
http://pilgrimwebdesign.com/ff4subselect

This issue affects a production web application at my place of employment, and is a pretty big deal to us as it will cause the application to render incorrectly.

Reproducible: Always

Steps to Reproduce:
1. Open the reduction or go to the URL
2. Click subselect on Michigan
3. Click subselect on Wisconsin
4. Notice that Michigan is no longer highlighted (EXPECTED)
5. Click show2
6. Click show1
7. (BUG) Notice that Michigan is once again highlighted
Actual Results:  
Michigan is highlighted after switching views, when it should not be.

Expected Results:  
Most major problem: Michigan should not have been selected.  

We would like the behavior from FF3 for all other edge cases as well (should Wisconsin remain selected, etc).

I have observed this behavior since FF4 Beta 8 or 9, but it may have existed prior to that.  In an older beta, the behavior changed, but is still broken.

Comment 1

[Lothsahn]

Attachment: Reduction of the issue affecting our web application

Comment 2

[Alice0775 White]

pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=749b2a61f372&tochange=6ed1d80316c0
triggered by:
178f26e21cfc	Ehsan Akhgari — Bug 597331 - Reframing a textarea sets the caret position to the end of its contents; r=bzbarsky a=blocking-final+

Comment 3

[Tim (fmdeveloper)]

Confirmed on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0

Comment 4

[(no longer active)]

Attachment: Patch (v1)

Jonas, it would be really great if you can review this soon.  I'd like to land this tonight...

Comment 5

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 525282 [details] [diff] [review]
Patch (v1)

r=me

Comment 6

[David Baron :dbaron:]

Landed:
http://hg.mozilla.org/mozilla-central/rev/b48ebf9695bb

Caused:

4737 ERROR TEST-UNEXPECTED-FAIL | /tests/layout/generic/test/test_selection_expanding.html | The contents of input aren't selected (input-input): Selected String: ""
4749 ERROR TEST-UNEXPECTED-FAIL | /tests/layout/generic/test/test_selection_expanding.html | The contents of input aren't selected (input-div3): Selected String: ""
4762 ERROR TEST-UNEXPECTED-FAIL | /tests/layout/generic/test/test_selection_expanding.html | The contents of textarea aren't selected (textarea-textarea): Selected String: ""
4774 ERROR TEST-UNEXPECTED-FAIL | /tests/layout/generic/test/test_selection_expanding.html | The contents of textarea aren't selected (textarea-div2): Selected String: ""

Backed out:
http://hg.mozilla.org/mozilla-central/rev/aa0b6404ec25

Comment 7

[David Baron :dbaron:]

(confirmed locally that it was the changeset causing that failure)

Comment 8

[(no longer active)]

Attachment: Patch (v2)

Oops, of course I meant SELECTION_HIDDEN, not SELECTION_OFF!  Sorry about that, David.  :(

Comment 9

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 525385 [details] [diff] [review]
Patch (v2)

r=me

Comment 10

[(no longer active)]

http://hg.mozilla.org/mozilla-central/rev/ca3565fa0f82

Comment 14

[Vlad [QA]]

This has been marked as Resolved Fixed but I can still reproduce this on Mozilla/5.0 (Windows NT 6.1; rv:6.0) Gecko/20100101 Firefox/6.0b3 build2 and also on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20100101 Firefox/6.0b3 build2

Comment 15

[Lothsahn]

Agreed.  The reduction attached to this issue still exhibits the problem as well:

http://pilgrimwebdesign.com/ff4subselect

Can we get this reopened, or did the fix land but hasn't yet hit a release?

Comment 16

[(no longer active)]

Indeed, the problem still happens on the original test case...

Comment 17

[(no longer active)]

Actually, I was wrong.  The testcase behaves fine.

Note that it is expected for Michigan to have a visible selection at the end, because the test case code focuses it.  But Wisconsin shouldn't have a visible selection (it currently does in Firefox 5, for example).

Comment 18

[Lothsahn]

Ehsan:

You're right.  The initial testcase actually is fixed now.  However, I think we're still seeing this behavior in our production application.  I think there may be yet another usecase triggering this bug.  I'll work on figuring out what that is and getting you a reduction, if the bug is still present.

It's definitely happening a lot less often than it was in FF4, at the very least...

Comment 19

[Lothsahn]

Ehsan:

I just had another developer do some testing, which hopefully resolves some or all of the confusion.

In Firefox 5 (his machine), he can reproduce the bug in our application AND the reduction.  
In Firefox 6 (my machine), I am unable to reproduce the bug in either our application or the attached reduction.

1) I will watch this issue closely and let you know if we see this bug occur on FF6 for our application.  If we see this issue occur, I will try to deliver you a reduction that reproduces the behavior.

2) Is it expected that FF5 did not have this fix?

Comment 20

[Lothsahn]

I should also mention that the behavior of FF6 matches Chrome and Safari, but not IE.  IE highlights neither Michigan NOR Wisconsin when you switch back to Pane 1.  All browsers do place the selection cursor inside the Michigan text area.

I did not test Opera.


P.S. I'm not suggesting that Firefox should determine its behavior based on what IE does, I just wanted to point out the difference in behavior. :)

Comment 21

[(no longer active)]

Firstly, yes.  This fix got into Firefox 6.  Firefox 5 still has this bug.

(In reply to comment #20)
> I should also mention that the behavior of FF6 matches Chrome and Safari, but
> not IE.  IE highlights neither Michigan NOR Wisconsin when you switch back to
> Pane 1.  All browsers do place the selection cursor inside the Michigan text
> area.

Yes.  IE doesn't highlight selections consistently (for example, when re-focusing a textfield containing a selection).  I'm not sure whether that's intentional or if they consider it a bug.

> P.S. I'm not suggesting that Firefox should determine its behavior based on
> what IE does, I just wanted to point out the difference in behavior. :)

Compatibility is good where it makes sense.  So, no need to feel bad about comparing the behavior to IE's.  :-)