Last Comment Bug 637671 - Highlighting broken with subselect and hiding/showing dom elements
: Highlighting broken with subselect and hiding/showing dom elements
Status: RESOLVED FIXED
: regression, testcase
Product: Core
Classification: Components
Component: Editor (show other bugs)
: Trunk
: x86_64 Windows 7
: -- normal (vote)
: mozilla6
Assigned To: :Ehsan Akhgari
:
:
Mentors:
http://pilgrimwebdesign.com/ff4subselect
: 650810 656007 667372 (view as bug list)
Depends on:
Blocks: 597331
  Show dependency treegraph
 
Reported: 2011-03-01 08:24 PST by Lothsahn
Modified: 2011-07-28 11:56 PDT (History)
11 users (show)
ehsan: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Reduction of the issue affecting our web application (2.17 KB, text/html)
2011-03-01 08:25 PST, Lothsahn
no flags Details
Patch (v1) (6.22 KB, patch)
2011-04-11 19:46 PDT, :Ehsan Akhgari
bzbarsky: review+
Details | Diff | Splinter Review
Patch (v2) (6.29 KB, patch)
2011-04-12 08:13 PDT, :Ehsan Akhgari
bzbarsky: review+
Details | Diff | Splinter Review

Description Lothsahn 2011-03-01 08:24:18 PST
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 2011-03-01 08:25:45 PST
Created attachment 515918 [details]
Reduction of the issue affecting our web application
Comment 2 Alice0775 White 2011-03-01 12:41:07 PST
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) 2011-04-11 15:30:38 PDT
Confirmed on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0
Comment 4 :Ehsan Akhgari 2011-04-11 19:46:58 PDT
Created attachment 525282 [details] [diff] [review]
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 [:bz] (still a bit busy) 2011-04-11 22:57:07 PDT
Comment on attachment 525282 [details] [diff] [review]
Patch (v1)

r=me
Comment 6 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2011-04-12 00:14:54 PDT
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: ⌚️UTC-7 (busy September 14-25) 2011-04-12 00:16:34 PDT
(confirmed locally that it was the changeset causing that failure)
Comment 8 :Ehsan Akhgari 2011-04-12 08:13:23 PDT
Created attachment 525385 [details] [diff] [review]
Patch (v2)

Oops, of course I meant SELECTION_HIDDEN, not SELECTION_OFF!  Sorry about that, David.  :(
Comment 9 Boris Zbarsky [:bz] (still a bit busy) 2011-04-12 20:58:19 PDT
Comment on attachment 525385 [details] [diff] [review]
Patch (v2)

r=me
Comment 11 Boris Zbarsky [:bz] (still a bit busy) 2011-04-29 20:25:48 PDT
*** Bug 650810 has been marked as a duplicate of this bug. ***
Comment 12 Boris Zbarsky [:bz] (still a bit busy) 2011-05-10 09:00:51 PDT
*** Bug 656007 has been marked as a duplicate of this bug. ***
Comment 13 Boris Zbarsky [:bz] (still a bit busy) 2011-06-26 19:48:09 PDT
*** Bug 667372 has been marked as a duplicate of this bug. ***
Comment 14 Vlad [QA] 2011-07-27 02:21:40 PDT
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 2011-07-27 07:25:34 PDT
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 :Ehsan Akhgari 2011-07-27 11:48:37 PDT
Indeed, the problem still happens on the original test case...
Comment 17 :Ehsan Akhgari 2011-07-27 11:57:29 PDT
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 2011-07-27 13:29:24 PDT
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 2011-07-27 13:39:41 PDT
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 2011-07-27 13:43:38 PDT
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 :Ehsan Akhgari 2011-07-28 11:56:45 PDT
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.  :-)

Note You need to log in before you can comment on or make changes to this bug.