Open Bug 1436801 Opened 7 years ago Updated 3 months ago

Vertical border and padding influences alignment of text in spans with "vertical-align:middle" (only in Firefox)

Categories

(Core :: Layout: Block and Inline, defect, P3)

57 Branch
defect

Tracking

()

Webcompat Priority P3

People

(Reporter: dholbert, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: webcompat:platform-bug, Whiteboard: [webcompat])

Attachments

(3 files)

(I'm not 100% sure who's correct here, but filing because we differ from all other major browsers on this -- so even if we happen to be correct, there's a webompat concern.) STR: 1. Load attached testcase. EXPECTED RESULTS: Consisten text position within each box. ACTUAL RESULTS: In the first orange box, "AAA" and "CCC" are pushed lower than "BBB". In the second orange box, "BBB" is pushed lower. Latest Chrome, Edge, and Safari give "expected results". Firefox gives "actual results". This is the underlying issue in this webcompat bug: https://github.com/webcompat/web-bugs/issues/12629
Component: Layout: Text → Layout: Block and Inline
Attached file testcase 1
This testcase is a bit more interesting, with different font sizes. At first glance, I think: - Chrome is honoring "vertical-align:middle" by lining up the center-line of the span's *line box* (excluding its padding) with the center-line of the line that it's participating in. (i.e. "AAA" is vertically centered with respect to the bounding box of the "BBB" text, and vice versa) - Firefox is doing the same, except that it's *includes the padding* (and probably border) when determining the center-line of the span. (i.e. "AAA" is vertically centered with respect to the *purple border-box* around "BBB")
[ Triage 2017/02/20: P3 ]
Priority: -- → P3

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Webcompat Priority: --- → ?

See bug 1547409. Migrating whiteboard priority tags to program flags.

Webcompat Priority: ? → revisit
See Also: → 1563715

I just ran into this bug at Fidelity's website (Mozilla's retirement 401k account provider, in the US)

STR there:
(1) Sign in at https://nb.fidelity.com/public/nb/401k/home
(2) Choose an employer account (in my case, I click "Mozilla")
This takes me to a dashboard with some header-tabs near the top, saying Summary | Contributions | Investments etc.
(3) Right-click the "Summary" text on that header-tab section of the page (to give it focus without actually activating its link)

ACTUAL RESULTS:
There's a few-pixel layout adjustment in that whole header-tab area -- it all gets a little shorter or shifts upwards, which means all of the other header-tabs ("Contributions | Investments", etc) shift upwards a bit.

EXPECTED RESULTS:
No such layout adjustment; the container shouldn't change size and the other tabs shouldn't move.

Chrome dev-edition 96 gives EXPECTED RESULTS; Firefox Nightly 95 gives ACTUAL RESULTS

At Fidelity's website, this is because of a :focus-triggered CSS rule which adjusts the padding on the "Summary" link; and the link happens to have vertical-align:middle, so this :focus styling ends up triggering a version of this bug and changing the size of the container.

(Similarly: in the testcases here, if you remove or change the padding on the vertical-align:middle thing, then it changes the size of the container in Firefox, but not in Chrome.)

Webcompat Priority: revisit → P3
Severity: normal → S3

The issue in https://github.com/webcompat/web-bugs/issues/12629 is fixed.

Hi Daniel, was wondering if you can still reproduce the issue with Fidelity from comment 6? Looks like it requires login credentials.
If yes, I'll file a breakage report for it and a KB entry :)

Flags: needinfo?(dholbert)

Here's a testcase similar to the previous one, but now using 'border' (as Fidelity does now).

Comparing Chrome vs. Firefox:

  • Chrome renders this testcase with each line's adjacent "BBB" and "CCC" text having the exact same vertical positioning, and with the orange border shrinkwrapping the height of the tallest text on the line (ignoring the one with the extra-large border).
  • Firefox renders this testcase with "BBB" and "CCC" having substantially different vertical positioning; and with the orange border being a bit taller than the "BBB" border-box but not as tall as the "CCC" border-box.
Flags: needinfo?(dholbert)

(In reply to Ksenia Berezina [:ksenia] from comment #7)

Hi Daniel, was wondering if you can still reproduce the issue with Fidelity from comment 6? Looks like it requires login credentials.

I can still reproduce it, though it's changed slightly -- Fidelity adds vertical border rather than vertical padding. I just attached testcase 3 to exercise that flavor of this issue.

I can file the breakage report with a screencast and more details, if you don't mind filing a KB entry. I'll adjust the title of this bug to indicate that border is relevant here, too (and that the alignment between vertical-align:middle content is influenced, too, as testcase 3 demonstrates).

If yes, I'll file a breakage report for it and a KB entry :)

Thanks! I can file a breakage report for Fidelity at least, since I can provide some details, but you go ahead and file the KB entry and then we can link them together.

Summary: Vertical padding influences baseline alignment of text around span with "vertical-align:middle" (only in Firefox) → Vertical border and padding influences alignment of text in spans with "vertical-align:middle" (only in Firefox)

(I spun off bug 1891625 for the fidelity breakage report; please link that to your kb entry when you file it. Thanks!)

Flags: needinfo?(kberezina)
Blocks: 1891626

(In reply to Daniel Holbert [:dholbert] from comment #10)

(I spun off bug 1891625 for the fidelity breakage report; please link that to your kb entry when you file it. Thanks!)

Filed, thanks!

Flags: needinfo?(kberezina)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: