Bug 23125 - Safari 3 CSS max-height with absolute positioned div
Summary: Safari 3 CSS max-height with absolute positioned div
Status: RESOLVED WORKSFORME
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: 525.x (Safari 3.2)
Hardware: Macintosh OS X 10.5
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-01-05 14:50 PST by Nick Crohn
Modified: 2011-08-03 11:54 PDT (History)
2 users (show)

See Also:


Attachments
Test case for the bug (31.42 KB, text/html)
2009-01-05 14:53 PST, Nick Crohn
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Crohn 2009-01-05 14:50:47 PST
This is a very odd bug which I will do my best to describe. What I believe is causing the problem is a CSS rendering problem in Safari 3 that is failing internally when performing a metrics calculation. (Just a guess based on what I've seen) The example I've attached illustrates the issue. It utilizes YUI components as well as some custom JS components used internally at the company I work for. I've narrowed down the CSS to the failing elements. The JS just exposes the problem but I don't believe it is causing the problem.

The problem appears to be with an absolutely positioned DIV that has a max-height with an overflow of auto. Now to create the problem it requires JS to be used. The auto fill textarea will grab an option element's text and place it in the textarea. When you select an item in the results the textarea becomes unusable and Safari 3 is unstable. The select below if changed, after causing the initial problem, displays bad text which changes each time the select is changed. If you also try and paste text into the textarea Safari will crash giving the following crash report (truncated):

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000008
Crashed Thread:  0

Thread 0 Crashed:
0   com.apple.WebCore             	0x94d15e42 WebCore::highestAncestor(WebCore::Node*) + 18
1   com.apple.WebCore             	0x94ea76cc WebCore::ApplyStyleCommand::applyBlockStyle(WebCore::CSSMutableStyleDeclaration*) + 188
2   com.apple.WebCore             	0x94ea11bf WebCore::ApplyStyleCommand::doApply() + 287

Now oddly enough if you create the problem and then scroll the page it re-renders the elements and the problem is no longer there. If in the CSS you remove the max-height attribute the problem no longer occurs.

Below is my system information:

OS: 		Leopard 10.5.6
Version:         3.2.1 (5525.27.1)
Build Info:      WebBrowser-55252701~1

I have also tried this in WebKit revision 39450 and was able to reproduce the bug. I could not reproduce the bug in Safari 2.0.4
Comment 1 Nick Crohn 2009-01-05 14:53:13 PST
Created attachment 26442 [details]
Test case for the bug

Added testcase.
Comment 2 Mark Rowe (bdash) 2009-01-05 15:47:40 PST
Can you provide some more explicit instructions on how to reproduce the problem using the test case?  It isn't obvious to me what steps are required.
Comment 3 Nick Crohn 2009-01-05 15:50:42 PST
(In reply to comment #2)
> Can you provide some more explicit instructions on how to reproduce the problem
> using the test case?  It isn't obvious to me what steps are required.
> 

Sorry about that.

1. Click "New Communication"

2. Start typing in the textarea, two or more characters. i.e. "le"

3. Click on one of the names in the list.

That should cause the error.
Comment 4 Robert Blaut 2009-01-05 23:24:34 PST
(In reply to comment #3)
> Sorry about that.
> 1. Click "New Communication"
> 2. Start typing in the textarea, two or more characters. i.e. "le"
> 3. Click on one of the names in the list.
> That should cause the error.

I cannot reproduce the reported problem in WebKit r39572.
Comment 5 Nick Crohn 2009-01-06 08:25:40 PST
(In reply to comment #4)
> (In reply to comment #3)
> > Sorry about that.
> > 1. Click "New Communication"
> > 2. Start typing in the textarea, two or more characters. i.e. "le"
> > 3. Click on one of the names in the list.
> > That should cause the error.
> 
> I cannot reproduce the reported problem in WebKit r39572.
> 

I just downloaded the r39572 build of WebKit and was able to reproduce again. Here is something I noticed, it required the overflow: auto to be active. i.e. a scroll bar on the right. If there wasn't a scroll bar the issue didn't come up. Try this exactly.

1. Click "New Communication"

2. Type "le" in the field (this will return a long list of results)

3. Click "Lileen Kenkines" from the list.

Optional: After the textarea goes blank also select a value from the select field below and that will show an issue caused by whatever state Safari is in.

Thanks.
Comment 6 Robert Hogan 2011-08-03 11:54:28 PDT
I cannot recreate this at all, nor can anyone else. Please re-open if you can provide a test case that can be recreated in any WebKit-based browser apart from Safari.