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

Issue 627149 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Nov 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 2
Type: Bug-Regression



Sign in to add a comment

text-indent behavior inconsistent with other browsers and earlier Chrome versions

Reported by ed.tram...@gmail.com, Jul 11 2016

Issue description

Chrome Version       : 51.0.2704.84 AND 51.0.2704.106 m
URLs (if applicable) : https://jsfiddle.net/etramell/nst5edtq/
Other browsers tested:
    Firefox: OK 46.0.1
         IE: OK 11.0.9600.17728

What steps will reproduce the problem?
(NOTE: The jsfiddle URL above provides easy access to this example.)
(1) Start with a labeled <button> element with a negative text-indent style.
(2) Observe that the button's label is either shifted or not visible, depending on the magnitude of the text-indent.
(3) Use JavaScript to insert a <div> element BEFORE the button's label text.
(4) Observe that the button's label is now centered normally, because the text-indent style applies only to the first line, and the new <div> has presumably assumed that "first line" position.
(5) Use JavaScript to remove the previously inserted <div> element.


What is the expected result?
The button's label should honor the text-indent style because the DOM has been restored to its initial state.

What happens instead?
In Chrome, the button's label stays centered, apparently ignoring the text-indent style.  In other browsers, the text-indent is honored as expected.

Please provide any additional information below. Attach a screenshot if
possible.

Something changed in Chrome very recently to cause this problem.  It was not a problem in Chrome version 50.0.2661.102, but it was first noticed in 51.0.2704.84, so the change happened somewhere between those versions.

Note that the example above (as illustrated in the jsfiddle page linked above) is a toy example, distilled to the minimal configuration needed to reproduce the bug.

The real-world use case is that of a button with a text label (for screen readers) and an icon.  Using text-indent to shift a button label out of view is a common practice.  This issue happens when adding "wait" feedback to the button in the form of a spinner (see http://spin.js.org/).  That code embeds a <div> element to draw the spinner (and it also applies a 'color: transparent' to hide the label since text-indent temporarily does not apply to it).  When the spinner is later removed, our Chrome users can see both the text label AND the icon inside the button, which is obviously undesired behavior.


 

Comment 1 Deleted

Labels: OS-Chrome
Cc: brajkumar@chromium.org
Status: Untriaged (was: Unconfirmed)
Able to reproduce this issue on Windows 7, Ubuntu 14.04 and Mac OS 10.11.5 using chrome Beta M50-52.0.2743.49.

Bisect Information:
=====================
Good build: 51.0.2678.0
Bad Build : 51.0.2679.0  

Change Log URL: https://chromium.googlesource.com/chromium/src/+log/b4dc9337cacb2152671ea1bcfbcbd236d6fbff20..e2f999841cbfba72585eef56746ab019c0db3b54

Unable to find the actual suspect from the above log, Could anyone please have a look in to this log and kindly assign it to the concerned owner.

Thanks!
Labels: -Type-Bug -Pri-3 M-54 hasbisect OS-Linux OS-Mac OS-Windows Pri-2 Type-Bug-Regression
Components: Blink>Layout
Cc: robhogan@chromium.org
Potentially Rob's change, maybe...?

Comment 7 by e...@chromium.org, Jul 22 2016

Owner: robho...@gmail.com
Status: Assigned (was: Untriaged)
Project Member

Comment 8 by bugdroid1@chromium.org, Jul 25 2016

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

commit 67818d55a1b15b97a96b7a74814e822024b0a346
Author: robhogan <robhogan@gmail.com>
Date: Mon Jul 25 19:53:06 2016

Collapse away nested anonymous blocks

https://crrev.com/59d3539fc7ce60355ccf52c00733d33dde5e118a stopped collapsing:

       LayoutBlockFlow (anonymous) at (0,0)
          LayoutBlockFlow (anonymous) at (0,0)
            LayoutInline {SPAN} at (0,0)

to

       LayoutBlockFlow (anonymous) at (0,0)
         LayoutInline {SPAN} at (0,0)

Reinstate that behaviour!

BUG= 627149 

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

[add] https://crrev.com/67818d55a1b15b97a96b7a74814e822024b0a346/third_party/WebKit/LayoutTests/fast/block/collapse-nested-anonymous-block-expected.html
[add] https://crrev.com/67818d55a1b15b97a96b7a74814e822024b0a346/third_party/WebKit/LayoutTests/fast/block/collapse-nested-anonymous-block.html
[modify] https://crrev.com/67818d55a1b15b97a96b7a74814e822024b0a346/third_party/WebKit/Source/core/layout/LayoutBlockFlow.cpp

Comment 9 by robho...@gmail.com, Nov 2 2016

Status: Fixed (was: Assigned)

Sign in to add a comment