I bisected this problem to the following changeset: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=9360c4975d3652abcae684e4af531fae7eb93789&tochange=c579ac37ac11a44b9af0c75720f519a40c439b19 Considering the content of the log, I think it is very probable that this is the commit which introduces the regression. Adding the blocking.
status-firefox57: --- → ?
tracking-firefox57: --- → ?
For the minimum working example, select the text box, type anything, hit enter, and then try to type again.
Has Regression Range: --- → yes
Component: Untriaged → Editor
Product: Firefox → Core
Status: UNCONFIRMED → NEW
status-firefox56: --- → affected
status-firefox57: ? → affected
Ever confirmed: true
Priority: -- → P1
ehsan, this is regression by bug 1385514. Could you look this? If no time, I will look this.
I'll take a look.
Assignee: nobody → ehsan
Attachment #8908659 - Attachment mime type: text/plain → text/html
I didn't end up having time to look into it today, sorry. I took half the day off sick. :/
Likely too late for 56 now.
status-firefox55: --- → unaffected
status-firefox56: affected → fix-optional
status-firefox-esr52: --- → unaffected
tracking-firefox57: ? → +
Version: 57 Branch → 56 Branch
Should thsi maybe be a 56 blocker? Maybe back something out instead?
[Tracking Requested - why for this release]: Yes, this needs to block 56. The decision in comment 7 was wrong. We should be able to very safely back out bug 1385514 from 56.
status-firefox56: fix-optional → affected
tracking-firefox56: --- → ?
OK, sounds like we should do that backout. This may affect many sites.
Fixed for Fx56 by backing out bug 1385514. https://hg.mozilla.org/releases/mozilla-beta/rev/678bea28fe03 (FIREFOX_56b13_RELBRANCH) https://hg.mozilla.org/releases/mozilla-release/rev/2bb9e6526ce9
status-firefox56: affected → fixed
The cause of the bug is that this branch ends up not being taken after bug 1385514: https://searchfox.org/mozilla-central/rev/1c13d5cf85f904afb8976c02a80daa252b893fca/editor/libeditor/EditorBase.cpp#2747 SetTextImpl() only gets called by WillSetText(), so we can fix this either by backing out the original change or by removing that condition. But I think the right thing to do is to do both actually, since there is no actual transaction any more, so it doesn't make much sense for SetTextImpl() to check whether subtransactions are supposed to modify the selection in the first place.
Created attachment 8909597 [details] [diff] [review] Don't prevent changing the selection in the editor when setting the value attribute
Attachment #8909597 - Flags: review?(masayuki)
Attachment #8909597 - Flags: review?(masayuki) → review+
I need to land this with the patch I posted in bug 1401225 which is pending review.
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/4193c11e97ae Don't prevent changing the selection in the editor when setting the value attribute; r=masayuki
Status: NEW → RESOLVED
Last Resolved: 8 months ago
status-firefox57: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla57
You need to log in before you can comment on or make changes to this bug.