My favorites | Sign in
Project Home Downloads Wiki Issues Code Search
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 136505: regression from Chrome 20 for table-cell displayed elements without explicit vertical-align
7 people starred this issue and may be notified of changes. Back to list
Status:  Fixed
Owner:  jchaffraix@chromium.org
Closed:  Aug 2012
Cc:  eae@chromium.org, rob...@roberthogan.net, kerz@chromium.org

Restricted
  • Only users with EditIssue permission may comment.


Sign in to add a comment
 
Reported by adam...@google.com, Jul 10, 2012
Chrome Version       : 21.0.1180.15 (Official Build 144745) dev
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
    Chrome 20:   OK !
     Safari 5:   not tested
Firefox 13.0.1:  OK
     IE 7/8/9:   not tested

What steps will reproduce the problem?
1. Open the attached baseline.html

What is the expected result?
1. The yellow boxes are aligned to the top of the pink box. Text is aligned vertically in the middle of the yellow box. (see expected.png)

What happens instead?
On Chrome 21 the yellow boxes are not aligned to the top. Instead, the last line of the text seems to be aligned, pushing the box with fewer lines of text down. (see chrome21.png)

Workarounds exist?
Yes, vertical-align: top can be specified on the yellow element

This was a live regression (from Chrome 20, and from current Firefox) observed first on https://www.google.com/settings/products.

baseline.html
599 bytes   View   Download
chrome21.png
4.6 KB   View   Download
Jul 10, 2012
#1 dub...@chromium.org
(No comment was entered for this change.)
Labels: -Area-Undefined Area-WebKit
Jul 10, 2012
#2 tkent@chromium.org
(No comment was entered for this change.)
Cc: jchaffraix@chromium.org
Labels: -Type-Bug Type-Regression WebKit-Rendering ReleaseBlock-Stable Mstone-21
Jul 10, 2012
#3 kar...@google.com
emil is this related to the other bugs u were looking at due to levi's change?
Status: Assigned
Owner: eae@chromium.org
Jul 10, 2012
#4 kar...@google.com
julien says he'll look ty julien!
Owner: jchaffraix@chromium.org
Cc: -jchaffraix@chromium.org eae@chromium.org
Jul 11, 2012
#6 jchaffraix@chromium.org
I confirm that it is a regression from http://trac.webkit.org/changeset/117339/
Jul 11, 2012
#7 rob...@roberthogan.net
WebKit's behaviour matches Opera. The adjacent CSS table cells are handled by an anonymous table, which treats the two cells as though they were in a row in the same table. FF treats them as separate elements with no interacting baseline. It's easy enough to fix - but it won't be clear without a bit of digging in the spec which behaviour is correct.
Jul 11, 2012
#8 jchaffraix@chromium.org
@robert, IE and FF agrees with our old behavior here.

I don't think I agree with your analysis: the 2 adjacent table cells are in *2* anonymous tables as they are not siblings (IIRC we sometimes allow some cells to share the same anonymous table wrapper but it's usually a bad idea). This means that they shouldn't impact each other's baseline and the 2 inline-blocks should be aligned. See the attached file (test case cleaned up more).
baseline.html
435 bytes   View   Download
Cc: rob...@roberthogan.net
Jul 11, 2012
#9 pim...@live.nl
Please forgive my ignorance - but is it really table-related? If I completely remove the cells from comment #8's test case (so as to have two wrappers only), I'm experiencing the same offset issue. Please see: http://jsfiddle.net/D2xqa/
Jul 11, 2012
#10 pim...@live.nl
My apologies, I missed the point - that works as expected. Sorry for the noise.
Jul 12, 2012
#11 rob...@roberthogan.net
jchaffraix: you're correct - I read the rendertree dump carelessly, they are in separate RenderTables. 

So the question is whether two inline-blocks should interact each other this way - similar to the way they would interact if they were both inline-tables. (Try your test case with inline-table to see what I mean).
Jul 12, 2012
#12 jchaffraix@chromium.org
Filed bug upsteam, the discussion will now happen there.
Labels: WebKit-ID-91137
Jul 12, 2012
#13 bugdro...@chromium.org
https://bugs.webkit.org/show_bug.cgi?id=91137
Labels: -WebKit-ID-91137 WebKit-ID-91137-NEW
Jul 17, 2012
#14 lafo...@google.com
(No comment was entered for this change.)
Labels: OS-All
Jul 19, 2012
#15 kar...@google.com
ping, just making sure you're still on this :)
Jul 19, 2012
#16 bugdro...@chromium.org
http://trac.webkit.org/changeset/123159
Labels: WebKit-Rev-123159
Jul 20, 2012
#17 jchaffraix@chromium.org
Due to the stable cut-off approaching, I decided to roll out the incriminating change from our release branch. This is the safest approach as it avoid rushing a half-baked change to stable (the risk of compatibility regression is pretty high on this code).
Jul 20, 2012
#18 jchaffraix@chromium.org
Rolled out the change on the M21 branch in http://trac.webkit.org/changeset/123251. Moving the bug to M22.
Labels: -Mstone-21 Mstone-22
Jul 30, 2012
#19 kerz@google.com
This appears to have had a CL land in webkit, is this fixed?
Jul 30, 2012
#20 kar...@google.com
no he reverted the problem CL in m21. but not trunk i believe.
Jul 30, 2012
#21 kar...@google.com
no he reverted the problem CL in m21. but not trunk i believe.
Jul 31, 2012
#22 jchaffraix@chromium.org
> no he reverted the problem CL in m21. but not trunk i believe.

Exactly, we can redo the stunt for M22 but I would rather avoid it. Let me dig deeper and solve this for good.

The situation is complex and the the new behavior seems to be correct per the spec (http://lists.w3.org/Archives/Public/www-style/2012Jul/0582.html).
Cc: kerz@chromium.org
Aug 1, 2012
#23 kerz@google.com
Ok, time is winding down for 22, if we don't have a solution by the weekend, can we revert for the time being?
Aug 3, 2012
#24 jchaffraix@chromium.org
> if we don't have a solution by the weekend, can we revert for the time being?

The more I look at the original change the more I think it's bogus. I intend to fix the issue properly and fear the fallouts so I would advise rolling the change on the M22 branch too.
Aug 6, 2012
#25 jchaffraix@chromium.org
Requesting a merge for the revert in anticipation of the M22 branch.
Labels: Merge-Requested
Aug 6, 2012
#26 jchaffraix@chromium.org
> The situation is complex and the the new behavior seems to be correct per the spec (http://lists.w3.org/Archives/Public/www-style/2012Jul/0582.html).

Correcting myself here, the spec was changed to match our old behavior per http://lists.w3.org/Archives/Public/www-style/2012Jul/0721.html. Patch posted upstream now that the issue is fully understood.
Aug 8, 2012
#27 kerz@google.com
(No comment was entered for this change.)
Labels: -Merge-Requested Merge-Approved
Aug 9, 2012
#28 jchaffraix@chromium.org
Reverted on M22 in http://trac.webkit.org/changeset/125209, moving to M23.
Labels: -Mstone-22 -Merge-Approved Mstone-23
Aug 10, 2012
#29 jchaffraix@chromium.org
Proper fix landed in http://trac.webkit.org/changeset/125229. Let me know if you still see the issue once the change has made it to the canaries.
Status: Fixed
Oct 13, 2012
#30 bugdro...@chromium.org
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Labels: Restrict-AddIssueComment-Commit
Mar 9, 2013
#31 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -Type-Regression -Area-WebKit -WebKit-Rendering -Mstone-23 Cr-Content Type-Bug-Regression M-23 Cr-Content-Rendering
Mar 13, 2013
#32 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Apr 5, 2013
#33 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -Cr-Content Cr-Blink
Apr 5, 2013
#34 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -Cr-Content-Rendering Cr-Blink-Rendering
Sign in to add a comment

Powered by Google Project Hosting