Empty div in contenteditable=true blocks are visible
Categories
(Core :: DOM: Editor, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr68 | --- | unaffected |
| firefox75 | --- | unaffected |
| firefox76 | --- | fixed |
| firefox77 | --- | fixed |
People
(Reporter: bob, Assigned: emilio)
References
(Regression)
Details
(Keywords: nightly-community, regression)
Attachments
(4 files)
div visible
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0
Steps to reproduce:
When I edit some document using ckeditor.
Actual results:
All the empty divs are visible and use space
Expected results:
Empty divs should collapse as before.
|
Reporter | |
Comment 1•4 years ago
|
||
|
|
Reporter | |
Comment 2•4 years ago
|
||
|
|
Reporter | |
Updated•4 years ago
|
|
|
Reporter | |
Comment 3•4 years ago
|
||
Using mozregression I found Bug 1098151
2020-04-09T18:10:30: INFO : Narrowed integration regression window from [39e8040f, 0bd7ed7c] (3 builds) to [39e8040f, 66e5251c] (2 builds) (~1 steps left)
2020-04-09T18:10:30: DEBUG : Starting merge handling...
2020-04-09T18:10:30: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=66e5251cc1e291fbd2196008433e5248602aa9e9&full=1
2020-04-09T18:10:32: DEBUG : Found commit message:
Bug 1098151 - Make empty editable blocks at least one line-height tall. r=jfkthame
Differential Revision: https://phabricator.services.mozilla.com/D68586
2020-04-09T18:10:32: DEBUG : Did not find a branch, checking all integration branches
2020-04-09T18:10:32: INFO : The bisection is done.
2020-04-09T18:10:32: INFO : Stopped
|
||
Updated•4 years ago
|
|
|
||
Comment 4•4 years ago
|
||
Confirmed on Mac OSX latest nightly
|
||
Comment 5•4 years ago
|
||
Emilio, it seems that your patch in bug 1098151 caused this regression, could you have a look please? Thanks
|
Assignee | |
Comment 6•4 years ago
|
||
Yeah, so... bug 1098151 was intentional because I didn't want to treat blocks differently depending on their DOM position... But it seems that other browsers do exactly that, so oh well.
|
|
Assignee | |
Comment 7•4 years ago
|
||
This is what other UAs do.
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/2ea41c3546d3 Restrict "empty editable block" bits to contenteditable roots. r=jfkthame
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/22849 for changes under testing/web-platform/tests
Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.
|
||
Comment 11•4 years ago
|
||
| bugherder | ||
Upstream PR merged by moz-wptsync-bot
|
||
Comment 13•4 years ago
|
||
The patch landed in nightly and beta is affected.
:emilio, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.
For more information, please visit auto_nag documentation.
|
|
Assignee | |
Comment 14•4 years ago
•
|
||
Comment on attachment 9139557 [details]
Bug 1628770 - Restrict "empty editable block" bits to contenteditable roots. r=jfkthame
As annoying as I always find the bot, in this case it's spot on.
Beta/Release Uplift Approval Request
- User impact if declined: comment 0
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce: comment 0
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Very simple tweak to a behavior change introduced in 76 to be more compatible with other UAs.
- String changes made/needed: none
|
||
Comment 15•4 years ago
|
||
Comment on attachment 9139557 [details]
Bug 1628770 - Restrict "empty editable block" bits to contenteditable roots. r=jfkthame
Approved for 76.0b5.
|
|
||
Comment 16•4 years ago
|
||
| bugherder uplift | ||
Description
•