[quirks] Chrome allows negative top margin on <button> to position them in transitional DTD, Firefox does not.
Categories
(Core :: Layout: Block and Inline, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox86 | --- | fixed |
People
(Reporter: twisniewski, Assigned: MatsPalmgren_bugz)
References
()
Details
(Keywords: parity-chrome, testcase)
Attachments
(2 files)
In the attached test-case, Firefox does not seem to honor the negative top margin on the button element, while Chrome does. This seems to be specific to the doctype declaration; if I drop it, then Firefox honors the negative margin (although the button position still does not quite match Chrome's position even in that case).
This is causing some text overlapping issues on haiaoedu.com, as reported at https://webcompat.com/issues/65186.
|
Assignee | |
Comment 1•3 years ago
|
||
Fwiw, this fixes the testcase:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=baa9ef6d0b15600c7f358aaf32f5af9fc9f16fa7
Let's see what the fallout is...
We check != eCompatibility_FullStandards rather than == eCompatibility_NavQuirks elsewhere in this file so it I suspect this line is an unintentional deviation.
|
|
Assignee | |
Comment 2•3 years ago
|
||
The line comes from bug 931853 and apparently I forgot to test "limited-quirks mode"... :-(
|
|
Assignee | |
Updated•3 years ago
|
|
|
Assignee | |
Comment 3•3 years ago
|
||
|
|
Assignee | |
Comment 4•3 years ago
|
||
nsLineLayout.cpp now checks:
CompatibilityMode() != eCompatibility_FullStandards
in all places.
Pushed by mpalmgren@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/c8f0bf3f70f5 [quirks] Apply line-height quirk code in both quirks and limited-quirks mode in all places. r=jfkthame
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/27210 for changes under testing/web-platform/tests
|
||
Comment 7•3 years ago
|
||
| bugherder | ||
Upstream PR merged by moz-wptsync-bot
Description
•