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.
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+
Confirmed on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: unspecified → 4.0 Branch
Jonas, it would be really great if you can review this soon. I'd like to land this tonight...
Attachment #525282 - Flags: review?(jonas)
Comment on attachment 525282 [details] [diff] [review] Patch (v1) r=me
Attachment #525282 - Flags: review?(jonas) → review+
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
(confirmed locally that it was the changeset causing that failure)
Oops, of course I meant SELECTION_HIDDEN, not SELECTION_OFF! Sorry about that, David. :(
Comment on attachment 525385 [details] [diff] [review] Patch (v2) r=me
Attachment #525385 - Flags: review?(bzbarsky) → review+
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla6
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
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?
Indeed, the problem still happens on the original test case...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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).
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago → 8 years ago
Resolution: --- → FIXED
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...
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?
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. :)
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. :-)
You need to log in before you can comment on or make changes to this bug.