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

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 3
Type: Bug



Sign in to add a comment
link

Issue 694374: Incorrect handling of whitespace inside CSS tables

Reported by bzbar...@mit.edu, Feb 21 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:54.0) Gecko/20100101 Firefox/54.0

Steps to reproduce the problem:
1. Load attached file

What is the expected behavior?
The two lines of text look identical

What went wrong?
All the spaces in the first line went away.

Did this work before? No 

Does this work in other browsers? N/A

Chrome version: 58.0.3013.3 (Official Build) dev (64-bit)  Channel: n/a
OS Version: OS X 10.12
Flash Version: 

This works correctly in Firefox and Edge.  WebKit has the same bug as Blink.
 

Comment 1 by bzbar...@mit.edu, Feb 21 2017

Note that I attached the file with the original report... but your captcha thing lost it.
baz.html
207 bytes View Download

Comment 2 by e...@chromium.org, Feb 21 2017

Owner: dgro...@chromium.org
David, is this a bug or intentional?

Comment 3 by e...@chromium.org, Feb 21 2017

Components: -Blink>Layout Blink>Layout>Table

Comment 4 by dgro...@chromium.org, Feb 21 2017

Labels: -Pri-2 Pri-3
Status: Assigned (was: Unconfirmed)
> David, is this a bug or intentional?

I don't know anything about whitespace collapsing but suspect bug because these should produce the same output but don't:

<div style="display:table">
  <span>This</span> <span>is</span> <span>some</span> <span>text</span>
</div>

<div style="display:table-cell">
  <span>This</span> <span>is</span> <span>some</span> <span>text</span>
</div>

https://jsfiddle.net/dgrogan/q7azLrww/

Comment 5 by bzbar...@mit.edu, Feb 22 2017

I should note that this has the potential for interop problems if people write code like this:

  <div style="display: table; width: 300px">
    <button style="width: 50%; display: table-cell">One</button>
    <button style="width: 50%; display: table-cell">Two</button>
  </div>

In this situation, all browsers actually make the buttons be inline-blocks in a single cell.  But in Chrome the space goes away so the buttons are on the same line, while in browsers that handle the whitespace correctly they will end up on two lines...

Comment 6 by francois...@outlook.com, Jun 20 2017

It would be nice to have this bug fixed. FWIW, here is the relevant spec text:

2.2.1. Fixup Algorithm

[...] The following steps are performed in three stages:

1 Remove irrelevant boxes:
- - [...]
- - Anonymous inline boxes which contain only white space *and* are between two immediate siblings each of which is a table-non-root box, are treated as if they had display: none.
- - Anonymous inline boxes which meet all of the following criteria are treated as though they had display: none.
- - - contains only white space
- - - are the first and/or last child of a tabular container
- - - whose immediate sibling, if it has any siblings at all, is a table-non-root box

Comment 7 by hey...@gmail.com, Apr 17 2018

The issue bz mentions in comment 5 is causing compatibility bugs such as https://bugzilla.mozilla.org/show_bug.cgi?id=1452870 to be filed against Firefox.

Comment 8 by bzbar...@mit.edu, Apr 17 2018

Cc: rbyers@chromium.org
Rick, could you get someone to take a look at this, please?  This is a longstanding WebKit bug that Blink inherited; the spec, sanity, Edge, and Firefox all agree on the behavior here but Chrome and Safari do something different...

Comment 9 by dgro...@chromium.org, Apr 17 2018

Cc: francois...@outlook.com dgro...@chromium.org
Owner: ----
Status: Available (was: Assigned)
> This is a longstanding WebKit bug that Blink inherited; the spec, sanity, Edge, and Firefox all agree on the behavior here but Chrome and Safari do something different...

Totally agreed that Blink behavior should change. But unfortunately these reasons apply to lots of bugs on our huge sucky backlog and we have to prioritize.

We haven't seen evidence that this bug is especially impactful, but if you (or anyone, including Francois Remy who commented above) have such evidence (many duplicates reported to FF, many instances surfacing on webcompat.com, affecting 1 or 2 big sites, etc) please tell us about it.

And thanks, heycam, for writing a test.

Comment 10 by bugdroid1@chromium.org, Apr 23 2018

Project Member
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d4fd62da30bfecc64d7d9bd17ce5904ca3333764

commit d4fd62da30bfecc64d7d9bd17ce5904ca3333764
Author: David Grogan <dgrogan@chromium.org>
Date: Mon Apr 23 10:47:46 2018

[css-tables] Move failing wpt test to its real bug

A test that blink fails was imported and given a new bug by the
importer. We already have a bug for this behavior.

Just bookkeeping.

Bug:  834311 ,694374
Change-Id: I101c3b5dc24da8df90330a33c633ae2864295dcf
Reviewed-on: https://chromium-review.googlesource.com/1023038
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/master@{#552664}
[modify] https://crrev.com/d4fd62da30bfecc64d7d9bd17ce5904ca3333764/third_party/WebKit/LayoutTests/TestExpectations

Comment 11 by dgro...@chromium.org, Jun 20 2018

 Issue 269500  has been merged into this issue.

Sign in to add a comment