User Agent: Mozilla/5.0 (Windows NT 6.1; rv:48.0) Gecko/20100101 Firefox/48.0 Build ID: 20160313030418 Steps to reproduce: 1. Visit any page which has <input> or <textarea> (e.g., TweetDeck's tweet field). 2. Type some text, and select the text (with mouse or touchpad). 3. Drag the selected text. 4. Drop it onto *a disabled area*, that is, don't insert it into other text. 5. Click the <input> or <textarea> to clear highlighting of text. Actual results: Caret disappeared. Expected results: Caret should appear.

This is a regression since Firefox 47, but might be related to Bug 1218162.

The problem is reproducible only in e10s. Regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=44986f66ee4b&tochange=8c81e97e0604 Regressed by : Bug 1121947

(In reply to Alice0775 White from comment #2) > The problem is reproducible only in e10s. > > Regression window: > https://hg.mozilla.org/integration/mozilla-inbound/ > pushloghtml?fromchange=44986f66ee4b&tochange=8c81e97e0604 > > Regressed by : Bug 1121947 and Bug 1121946

I don't see this issue, but the attached url has no disabled input field, as described in the original steps. Can you provide better steps and testcase?

(In reply to Neil Deakin from comment #4) > I don't see this issue, but the attached url has no disabled input field, as > described in the original steps. Can you provide better steps and testcase? Not disabled element. "disabled" means "no-drop" region, in this bug. Steps To Reproduce: 1. Open the URL 2. Select "12345678" 3. Drag the selected text 4. Drag over "12345678" --- you should see "no-drop" mouse cursor as expected 5. Release the mouse button on the "12345678" --- Nothing happens as expected 6. Click input field Actual Results: Caret(text insertion I beam) is not shown Expected Results: Caret should be shown

I can only reproduce this on Windows. Perhaps a dragexit event isn't being sent to the content process.

oot How came that this bug has priority P1 and _my_ bug 1233612 has P4? (set by the same person) Is this something personal?

I wouldn't read too much into what the priority was set as. I suspect this bug was set as a P1 because this bug has simpler steps to reproduce.

I mean, this is pretty clear. I reported 2 bugs which are literally the same (1st of them was reported 4_month_ago), then somebody reported the same bug and it gets fixed in a few days. The bad thing is only time wasted for writing 2 bugs. I wrote hundreds of reports. This isn't the 1st time it happens, so I'd like to know some workaround... Should I mark any bug as regression? E.g. "implementation of <panel> caused this bug with panel, so it's regression"? (like in this bug) And set NI. I get it.

We triaged this with Jeff, this bug seemed more serious than the other, which involved cancelling a drag using escape.

The dragexit event can be fired with coordinates outside the remote browser, so use the last target instead.

https://hg.mozilla.org/integration/mozilla-inbound/rev/e52f19e73317d1e009b171ee137d7185c3bf9fda Bug 1256162, use last drag target for dragexit event when comparing to a remote browser, r=smaug

I've confirmed this issue was fixed in 48.0a1 (2016-03-20). Thank you for handling this! ;)

Neil, should this fix be uplifted to Aurora 47 in preparation for our e10s experiments on Beta 47?

I think so. It causes drag events to not fire.

But bug 1256952 should go along with it.

Comment on attachment 8732324 [details] [diff] [review] Use last target for dragexit event Approval Request Comment [Feature/regressing bug #]: [User impact if declined]: Caret in textarea disappears because drag events to not fire. [Describe test coverage new/current, TreeHerder]: The fix has been baking on Nightly 48 for two weeks and was verified fixed by the bug reporter in comment 17. [Risks and why]: bug 1256952 should go along with it. [String/UUID change made/needed]: None

Comment on attachment 8732324 [details] [diff] [review] Use last target for dragexit event Fix was verified, Aurora47+