Closed Bug 1256162 Opened 4 years ago Closed 4 years ago

Caret in <input> or <textarea> disappears after we drag & drop text onto a disabled area

Categories

(Core :: Layout: Form Controls, defect, P1)

47 Branch
defect

Tracking

()

VERIFIED FIXED
mozilla48
Tracking Status
e10s m9+ ---
firefox46 --- wontfix
firefox47 --- fixed
firefox48 --- fixed

People

(Reporter: r_kato, Assigned: enndeakin)

References

(Blocks 1 open bug, )

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

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.
Keywords: regression
Summary: Caret disappears after drag & drop <input> or <textarea> → Caret in <input> or <textarea> disappears after we drag & drop text onto a disabled area
Blocks: 1252801
Component: Untriaged → Layout: Form Controls
Product: Firefox → Core
tracking-e10s: --- → ?
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
Blocks: 1121947
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(enndeakin)
Flags: needinfo?(bugs)
(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
Blocks: 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?
Flags: needinfo?(enndeakin)
Flags: needinfo?(bugs)
Flags: needinfo?(alice0775)
(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.
Priority: -- → P1
Assignee: nobody → enndeakin
Status: NEW → ASSIGNED
See Also: → 1233612
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.
Duplicate of this bug: 1233612
Blocks: 1256952
The dragexit event can be fired with coordinates outside the remote browser, so use the last target instead.
Attachment #8732144 - Attachment is obsolete: true
Attachment #8732324 - Flags: review?(bugs)
Attachment #8732324 - Flags: review?(bugs) → review+
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
https://hg.mozilla.org/mozilla-central/rev/e52f19e73317
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
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?
Flags: needinfo?(enndeakin)
I think so. It causes drag events to not fire.
Flags: needinfo?(enndeakin)
But bug 1256952 should go along with it.
Status: RESOLVED → VERIFIED
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
Attachment #8732324 - Flags: approval-mozilla-aurora?
Comment on attachment 8732324 [details] [diff] [review]
Use last target for dragexit event

Fix was verified, Aurora47+
Attachment #8732324 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.