New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 689643 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
NOT IN USE
Closed: Feb 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

Element position changes after toggling display property to none and back

Reported by a...@mrph.org, Feb 7 2017

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.21 Safari/537.36

Steps to reproduce the problem:
1. Load the attached HTML. Note position of the "Foo" text.
2. Enable the "display: none" property on the surrounding span. (Either adding it through devtools or via the included media query [by making the window small].)
3. Disable the "display: none" property. (Either by removing it in devtools or making the window wider again.)
4. Observe the "Foo" text is now rendered in a different position than it was before, even though the DOM and styles are the same as step 1.

What is the expected behavior?
The element should render in the same position as it did originally.

What went wrong?
The element renders lower than it did before the additional style was applied and removed.

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 57.0.2987.21  Channel: beta
OS Version: 57.0.2987.21
Flash Version: 

Tested in Firefox 45.4.0 and it renders the element at it's original position.

I ran across this issue on a real project (that part was written by a developer who uses Firefox), though it is not public yet.

It shouldn't be too hard to work around, since it seems to require display:flex, position:absolute, toggling display:none, and a block element following an inline element with somewhat unusual nesting. It did take quite a while to figure out how to reproduce the issue though.

 

Comment 1 by a...@mrph.org, Feb 7 2017

It looks like the attached minimal(ish) example got lost, so here it is again.
foo.html
290 bytes View Download
Labels: Needs-Feedback
Hi,

We tried to reproduce with the sample & instructions provided but it all seems to be working correctly.

Can you perhaps include screen shots or a short video of the behavior that you're observing so we can analyze further.

Comment 3 by ajha@chromium.org, Feb 8 2017

Labels: Needs-Triage-M57

Comment 4 by a...@mrph.org, Feb 8 2017

Certainly. Attached are screenshots taken with Google Chrome 58.0.3004.3 (updated today), reproducing the issue via devtools.

I would expect step-1 and step-3 to render the same, but as you can see, the text is now overlapping.


689643-step-1.png
49.0 KB View Download
689643-step-2.png
46.1 KB View Download
689643-step-3.png
52.4 KB View Download
Project Member

Comment 5 by sheriffbot@chromium.org, Feb 15 2017

Labels: -Needs-Feedback Needs-Review
Owner: slangley@chromium.org
Thank you for providing more feedback. Adding requester "slangley@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 6 by meade@chromium.org, Feb 16 2017

Cc: meade@chromium.org slangley@chromium.org
Labels: -Needs-Review Needs-Bisect
Owner: ----
Status: Untriaged (was: Unconfirmed)
Seems to be a valid problem. Works as expected in Firefox.

Reproduced in both 56.0.2924.87 and 58.0.3011.0 (linux).

Needs bisect. You've got to set display:none in the inner span, not the outer one. Resizing the window also worked for me. If you still have trouble reproducing for the bisect feel free to ping me.

Comment 8 by r...@opera.com, Feb 16 2017

Components: -Blink>CSS Blink>Layout
More likely that this is Blink>Layout.

Comment 9 by msten...@opera.com, Feb 16 2017

Owner: msten...@opera.com
Status: Assigned (was: Untriaged)
Project Member

Comment 10 by bugdroid1@chromium.org, Feb 19 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/77ec19ddefb32688cd18277ed7412531b536401a

commit 77ec19ddefb32688cd18277ed7412531b536401a
Author: mstensho <mstensho@opera.com>
Date: Sun Feb 19 18:59:04 2017

Add out-of-flow objects under the inline in a continuation chain, when possible.

The same goes for floating objects. Only when a floating or out-of-flow
positioned object is to be added between two block-level children should we add
it to the anonymous block box holding the block-level children. If the new
child is to be added before a block-level child, and this beforeChild is the
first block-level child, we should rather make the new child the last child of
the preceding inline, rather than the first child of the anonymous block
containing block-level children.

Also cleaned up and documented the code somewhat.

BUG= 689643 

Review-Url: https://codereview.chromium.org/2698243002
Cr-Commit-Position: refs/heads/master@{#451525}

[add] https://crrev.com/77ec19ddefb32688cd18277ed7412531b536401a/third_party/WebKit/LayoutTests/fast/inline/add-abspos-before-block-inside-inline-expected.html
[add] https://crrev.com/77ec19ddefb32688cd18277ed7412531b536401a/third_party/WebKit/LayoutTests/fast/inline/add-abspos-before-block-inside-inline.html
[modify] https://crrev.com/77ec19ddefb32688cd18277ed7412531b536401a/third_party/WebKit/Source/core/layout/LayoutInline.cpp

Comment 11 by msten...@opera.com, Feb 20 2017

Status: Fixed (was: Assigned)

Sign in to add a comment