Text selection handles visible after removing textarea

NEW
Unassigned

Status

()

3 years ago
3 years ago

People

(Reporter: ivan, Unassigned)

Tracking

37 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments)

(Reporter)

Description

3 years ago
Created attachment 8599769 [details]
Screenshot_2015-04-30-11-11-10.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0 Iceweasel/35.0.1
Build ID: 20150130021009

Steps to reproduce:

I've made a test case at https://gist.github.com/IvanSanchez/19236943e971c09263d3

It seems that the necessary conditions to reproduce this are:
- Programatically select all text in a textarea
- Manually deselect and select some text
- Attach a jQuery 'focusout' event handler to a textarea
- Hide the parent element of the textarea on a timeout on the focusout element handler




Actual results:

The text selection handles will remain visible (and draggable) on the screen, *even when switching to any other tab*.
(Reporter)

Comment 1

3 years ago
Created attachment 8599770 [details]
Screenshot_2015-04-30-11-10-53.png
logcat errors are:

D/GeckoBrowser(25359): Unexpected failure during caret attach: Element disabled, handled natively, or not editable.
Error: "NS_ERROR_NOT_INITIALIZED: Component returned failure code: 0xc1f30001 (NS_ERROR_NOT_INITIALIZED) [nsIEditor.selection]" {file: "chrome://browser/content/SelectionHandler.js" line: 936}]


Tricky edgecase! We're trying to attach a caret into the textarea that no longer contains an editor, and we fail in _clearSelection() while trying to determine how properly to close the previous selection first.

http://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/SelectionHandler.js?rev=1be077af56e3&mark=1209-1209#1204


fyi, we're currently migrating towards Bug 1168847 - [meta] Enable Gecko text selection carets by default, and this won't be an issue there.
Forgot I wanted to thank ivan for the report and the detailed testcase (That's always extremely helpful!), and to apologise that I didn't notice this for some reason earlier.

Updated

3 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 4

3 years ago
(In reply to Mark Capella [:capella] from comment #3)
> Forgot I wanted to thank ivan for the report and the detailed testcase
> (That's always extremely helpful!), and to apologise that I didn't notice
> this for some reason earlier.

No problem, Mark. I know how being on that side of the bugtracker feels like ;-)
Checking back in with Ivan. Our new AccessibleCaret implementation completely replaces the old Java handles involved in this issue. General code changes (testable in nightly) seem to corrected (new) / invalidated (old) this problem.

Can you try this out and confirm my own testing? We're trying to close as many old issues as possible, where appropriate.
Flags: needinfo?(ivan)
(Reporter)

Comment 6

3 years ago
I've just tested with Firefox Nightly 47.0a1 (2016-02-11).

Apparently I'm still able to reproduce the bug, albeit with a different set of event handlers and timeouts than originally (the one I used to workaround the original bug). I haven't had time to isolate the problem. I'll attach some screenshots.

The *good* part is that, even though the handles are visible when the <textarea> is not, the handles do dissapear as soon as any other element in the page is focused (i.e. as soon as the user touches anything). So now it's more like a small glitch and less than a ux-breaking bug.

[:capella] : I don't know if the right course of action is to close the bug or downgrade it to "trivial" importance and spend time isolating the minimal conditions to trigger it.
Flags: needinfo?(ivan)
(Reporter)

Updated

3 years ago
Flags: needinfo?(markcapella)
(Reporter)

Comment 7

3 years ago
Created attachment 8718783 [details]
Screenshot_2016-02-12-12-31-10.png - selecting text
(Reporter)

Comment 8

3 years ago
Created attachment 8718784 [details]
Screenshot_2016-02-12-12-31-40.png - handles still visible
I think you said there's new STR and test-code than what you posted in comment 0 to force this bug (?) Can you post that also? In any case, let's leave this open for now.
Flags: needinfo?(markcapella)
You need to log in before you can comment on or make changes to this bug.