969880 - Incorrect baseline alignment for 'inline-flex' container, whose only flex item has overflow other than visible and top padding

Status: RESOLVED DUPLICATE of bug 1797982

(Core :: Layout, defect, P4)

Description

[Roman Komarov]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.12786 YaBrowser/13.12.1599.12786 Safari/537.36

Steps to reproduce:

Note: this is not a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=969874 I guess, at least it not looks as one.

1. Add some blocks with `display: inline-flex`
2. Add inner elements inside of them.
2. Give some of the inner elements `overflow` other than `visible`.
3. Add top padding to this inner element.
4. Use `vertical-align: baseline` for the parent ones.

See this example: http://dabblet.com/gist/8887207, note that in all other browsers this example behaves properly.



Actual results:

Element with `display: inline-flex` and `overflow` other than `visible` on inner element have an incorrect baseline, shifted to the amount of its top padding.



Expected results:

Element with `display: inline-flex` and `overflow` other than `visible` on inner element should have proper baseline.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: reporter's testcase

Comment 2

[Daniel Holbert [:dholbert]]

Confirming the reporter's suspicion from comment 0: this is indeed not a duplicate of bug 969874 -- that bug is now fixed in Nightly, but this bug's behavior doesn't seem to have changed.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 10 votes.
:dholbert, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 4

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Comment 5

[Roman Komarov]

Testing this one — I think it can be closed, as I cannot reproduce it neither in stable or nightly Firefox anymore.

Comment 6

[Daniel Holbert [:dholbert]]

Thanks for the update! Using mozregression --find-fix, it looks like we fixed this in bug 1797982 which was really a dupe of this one, though we didn't notice at the time.

--> Duping to that bug where the fix landed.