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
Created attachment 26442 [details] Test case for the bug Added testcase.
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.
(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.
(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.
(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.
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.