Bug 17028

Summary:

REGRESSION: Buttons no longer wrap in table cell

Product:

WebKit

Reporter:

Steve Nicolai <snicolaitv>

Component:

Layout and Rendering

Assignee:

Dave Hyatt <hyatt>

Status:

RESOLVED CONFIGURATION CHANGED

Severity:

Normal

CC:

ahmad.saleem792, bdakin, giffypap79, gsherloc, hyatt

Priority:

Keywords:

HasReduction, InRadar, Regression

Version:

523.x (Safari 3)

Hardware:

Mac

OS:

OS X 10.4

URL:

http://kakuro.cc/

Attachments:

Description	Flags
Reduced test case	none
Always treat all form controls as replaced elements.	none
More work in progress	none
More work in progress (pretty much done).	none

Steve Nicolai

Reported 2008-01-26 19:10:41 PST

MacOS 10.4.11 with Safari/WebKit Version 3.0.4 (523.12.2) WebKit 523 renders all six buttons on one line, extending beyond the table cell to the right. WebKit 312 and Camino render the buttons as two rows of three buttons contained within the table cell. Works on MacOS 10.3.9 with Safari/WebKit 1.3.2 (312.6). Also works properly on Camino 1.5.4 on 10.4.11 (Intel)

Attachments
Reduced test case (1.12 KB, text/html) 2008-01-26 19:11 PST, Steve Nicolai	no flags	Details
Always treat all form controls as replaced elements. (2.91 KB, patch) 2008-01-28 14:47 PST, Dave Hyatt	no flags	Details Formatted Diff Diff
More work in progress (7.43 KB, patch) 2008-01-29 10:56 PST, Dave Hyatt	no flags	Details Formatted Diff Diff
More work in progress (pretty much done). (11.06 KB, patch) 2008-01-29 20:02 PST, Dave Hyatt	no flags	Details Formatted Diff Diff
Show Obsolete (2) View All Add attachment proposed patch, testcase, etc.

Steve Nicolai

Comment 1 2008-01-26 19:11:44 PST

Created attachment 18714 [details] Reduced test case

Dave Hyatt

Comment 2 2008-01-28 12:43:41 PST

I'll take this.

Dave Hyatt

Comment 3 2008-01-28 13:24:06 PST

This was a regression from Safari 2 to Safari 3 caused by the changes to calcInlinePrefWidths for this tables/images IE quirk. Beth did the original code and I recently re-wrote it. Both of our implementations have this bug. :)

Dave Hyatt

Comment 4 2008-01-28 13:24:32 PST

Actually these are buttons, so I may be wrong about the cause of this regression.

Alice Liu

Comment 5 2008-01-28 13:34:48 PST

please check radar for an update.

Alice Liu

Comment 6 2008-01-28 13:35:50 PST

<rdar://problem/5710787>

Dave Hyatt

Comment 7 2008-01-28 14:47:49 PST

Created attachment 18744 [details] Always treat all form controls as replaced elements. This is a preliminary patch. I need to run the layout tests and do some testing to make sure that block-level form controls don't start malfunctioning with this patch.

Dave Hyatt

Comment 8 2008-01-29 10:56:46 PST

Created attachment 18765 [details] More work in progress

Dave Hyatt

Comment 9 2008-01-29 20:02:54 PST

Created attachment 18788 [details] More work in progress (pretty much done).

Gavin Sherlock

Comment 10 2009-09-19 01:52:05 PDT

The test case seems to render correctly now (in Safari 4.03, as well as r48518) - maybe this is fixed and can be closed?

Steve Nicolai

Comment 11 2009-09-19 08:04:36 PDT

This works for me with Safari 4.0.3(4531.9) as well. Tested on PowerPC Tiger 10.4.11.

Ahmad Saleem

Comment 12 2022-09-01 16:43:48 PDT

All browsers (Safari Technology Preview 152, Firefox Nightly 106 and Chrome Canary 107) render this same and only difference is styling of button, which is subject to browsers to use system native or customised, so it is intended. I am going to mark this as "RESOLVED CONFIGURATION CHANGED", please reopen if it is not fixed. Thanks!

Note You need to log in before you can comment on or make changes to this bug.