1130866 - Omnipaste viewport too wide (due to content being mispositioned) after "Get Omnipaste" is clicked & dismissed

Status: RESOLVED DUPLICATE of bug 478834

(Core :: Layout, defect)

Description

[Daniel Holbert [:dholbert]]

Filing bug for issue reported in this thread on twitter:
https://twitter.com/ZenoPopovici/status/564458552967036928

STR:
 1. Load https://www.omnipasteapp.com/
 2. Click "Get Omnipaste"
  --> an overlay swoops down
 3. Click the "x" at the upper-right of overlay to dismiss it.

ACTUAL RESULTS:
A horizontal scrollbar appears on your window. If you scroll down the page, and then scroll over, you can see that the second section ("Copy/Pasting Text") is now positioned way off to the right for some reason (which is creating the horizontal scrollbar).


It sounds like there may be a hackaround uploaded to the site at some point, but hopefully we can get the developers to keep up a broken version somewhere (or provide steps to re-break the hacked-around version).

Comment 1

[Daniel Holbert [:dholbert]]

I can trigger what looks like a form of this bug by restyling the ".container" element around the first screen's contents ("Link your PC to your Android device" etc) with a small width.

That obviously ruins the layout of that section, but it also pushes the next section ("Copy/Pasting Text") over to the right. (It does not have that effect in Chrome, so this is still a Firefox-specific effect.)

Comment 2

[Daniel Holbert [:dholbert]]

For some reason, I can fix both issues (preventing stuff from being pushed off to the right) if I add this style to the page:
  main { border: 1px solid lime; }

Comment 3

[Zeno Popovici]

Here's a copy of the broken version for debugging: http://play.graffino.com/www.omnipasteapp.com/index.html

Comment 4

[Zeno Popovici]

Screencast: http://zeno.in/ZgEv

Comment 5

[Daniel Holbert [:dholbert]]

Thanks, Zeno.

Following up on the Magic CSS Rule in comment 2 a bit more: once I've triggered the original bug here, I can fix it by briefly enabling and then disabling that single CSS rule (via a checkbox in devtools, or via the "Stylish" addon).

This confirms for me that there's indeed a Gecko bug here -- our final rendering shouldn't change as a result of a CSS rule being added & removed.

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: reduced testcase 1 (maybe)

Here's a reduced testcase that shows the difference between Firefox & Chrome described in comment 1 at least.

At least in this testcase, there's a float-handling difference between Chrome & Firefox. The testcase has a tall float inside of one block, and a wide flex container inside of the next block. Firefox puts the flex container alongside the tall float; chrome pushes the flex container down to be below the float.

I'm not sure which is correct here (floats are complicated, and I've mostly-successfully managed to avoid them).  But I'll note that Chrome seems to be inconsistent with itself here, which raises suspicion.  Specifically, if I change the wide flex container to be a wide *block* instead, then Chrome switches to match the Firefox rendering. So they're doing something special for flex containers here, which is odd.  (Or alternately, they're doing something special for blocks, separate from other block-level display-types; in particular, they treat "display:table" like "display:flex" here. Just "display:block" [which makes them match Firefox] seems to be the odd one out.)

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: testcase to demonstrate tall-float interaction with later flex/table/block container

I was going to file a Chrome bug on the inconsistency mentioned above, but it turns out we're inconsistent too, though in a slightly different way. (so that makes me sure that Chrome's inconsistency is clearly-wrong)

Here's a testcase to demonstrate an interaction between a tall float & a later flex container / table container / block container.

Firefox & Chrome agree on the last third of this testcase -- with a block intersecting the earlier tall float -- but they disagree on the first two thirds of the testcase (with the container having display:flex/display:table). Chrome wraps the container below the float; Firefox positions the container to the right of the float. Each of these behaviors is different from the common block-container behavior -- there, Firefox & Chrome agree to have the block overlap the float, and push the block's contents to the right of the float.

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: reduced testcase 2 (only partly reduced) Click text or red box --> scrollbar appears. Resize window --> scrollbar disappears.

Comment 9

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #2)
> For some reason, I can fix both issues (preventing stuff from being pushed
> off to the right) if I add this style to the page:
>   main { border: 1px solid lime; }

Unsurprisingly (given that float weirdness is involved), a well-targeted "clear:both" declaration also fixes this. Specifically, this works for me:
  main { clear: both }

(This avoids the "is orange area to right of blue, or below it" inconsistency between Chrome & Firefox on "reduced testcase 1" here, and it seems to similarly bring Chrome & Firefox into consistency on the actual original page.)

Comment 10

[Daniel Holbert [:dholbert]]

I'm pretty sure a lot of this bug is essentially the same as bug 1073574, though with a flex container instead of a table. (As shown by attachment 8561071 [details] here, tables & flex containers behave the same when it comes to interacting with floats that come before them in the document.)

Marking as a dependency for now (instead of a duplicate), since there does seem to also be an incremental layout bug involved here as well, as revealed by the scrollbar appearing in attachment 8561087 [details] and then disappearing if you resize the window.

Comment 11

[j.j.]

This is fixed now on current Nightly 42 by bug 478834