Bug 23814

Summary: Crasher: Random unicode characters inserted into select options and
Product: WebKit Reporter: James Wheare <james>
Component: Layout and RenderingAssignee: Nobody <webkit-unassigned>
Severity: Critical CC: ap, jamesr, mitz
Priority: P2    
Version: 525.x (Safari 3.2)   
Hardware: Macintosh   
OS: OS X 10.5   
URL: http://www.last.fm/music/+noredirect/Trentemoller
Description Flags
crash log none

Description James Wheare 2009-02-06 20:44:07 PST
Steps to reproduce

1. Log in to Last.fm. http://www.last.fm/login

Test account if needed:
user: safaribug
password: 123

2. On this page click the "Flag this" link in the yellow bar at the top of the page:

3. In the floating absolute positioned div, select the "another artist..." option from the <select> drop down.

BUG: Strange characters are inserted in to the option content, over-writing existing content.

Expected behaviour:
* Option content should be untouched
* A new text field should appear underneath as a result of an onchange handler on the select element.

This event handler is not reached, script execution appears interrupted.

If you continue to use the <select> drop down after this, Safari will eventually crash.

I've narrowed this down and removed all markup and event handlers in the hovering window other than the select and this behaviour still occurs.

Let me know if there's any more specific narrowing down I can do to reduce this case.
Comment 1 James Wheare 2009-02-06 20:51:14 PST
This looks fixed in the latest nightly. I'd like to know the cause of this bug so I can workaround it though.
Comment 2 Alexey Proskuryakov 2009-02-07 03:52:40 PST
Marking WORKSFORME per the above comment.

The best way to discover the reason is to find out when the problem stopped happening. You can use the nightly build archive at <http://nightly.webkit.org/> to find a pair of consequent revisions, and then the commit logs at <http://trac.webkit.org> to find a commit that looks relevant.
Comment 3 James Wheare 2009-02-07 07:53:26 PST
Well I managed to identify it as somewhere between these two:


But now suddenly when I try to load any URL in those revisions or any in between the app crashes with:

*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** +[NSString _webkit_localCacheDirectoryWithBundleIdentifier:]: unrecognized selector sent to class 0xa008ef20'

Annoyingly this doesn't happen with the latest nightly, so it's not a new bug worth filing as it will only get closed as WORKSFORME.

Not sure how to proceed, I've tried removing all plugins, reinstalling Safari, using a fresh user account. This is happening on two separate machines.

Crash log attachment to come. I'd really like to track down this issue as I can't really wait for the next release of Safari.
Comment 4 James Wheare 2009-02-07 07:54:07 PST
Created attachment 27446 [details]
crash log
Comment 5 Mark Rowe (bdash) 2009-02-07 11:05:04 PST
The error about _webkit_localCacheDirectoryWithBundleIdentifier indicates you're running a nightly build that predates Safari 3.2 against Safari 3.2.  This won't work, as older WebKit frameworks are missing functionality that Safari 3.2 needs.  To look back in time before previous Safari releases you'll often need to install an older Safari version to avoid problems like this.
Comment 6 James Wheare 2009-02-07 12:02:09 PST
Are older versions of Safari still available for download from Apple? All the old links I could find either redirect to the Safari product or developer support page. I remember there used to be a reference table of Webkit revision to Safari version. This too seems to be no longer.
Comment 7 James Wheare 2009-02-07 12:18:01 PST
I suppose this is probably the best I'll get for looking up revision numbers corresponding to releases:

Comment 8 James Wheare 2009-02-07 15:39:07 PST
For the benefit of Google:

I managed to isolate a reduced test case here:

The setup involves a <select> with at least two <option> children inside a position:fixed container which is itself contained by a position:relative element.

Then with javascript:
1. Set the position of the fixed container to absolute
2. Access the container's clientWidth or clientHeight properties
3. Restore the position of the container to fixed

After these operations, select a different option from the drop down and it's text content will be munged with random characters.

This particular test case doesn't trigger the crash, but it's probably the root symptom.

This may seem like quite a strange operation but is used in the Prototype.js Element.getDimensions method:

Thankfully it's fixed in the latest Webkit nightly but knowing what triggers it should help any web developers who encounter this issue in the mean time.
Comment 9 James Wheare 2009-02-09 18:28:09 PST
More info including possible workarounds:

Comment 10 James Wheare 2009-03-04 03:59:14 PST
This behaviour is still happening in the Safari 4 public beta. Is that using an older version of webkit?
Comment 11 Alexey Proskuryakov 2009-03-04 04:13:41 PST
I can reproduce this with a local debug build of r41380 (using the reduction at <http://james.wheare.org/stuff/bugs/safari/fixedselect>).
Comment 12 Alexey Proskuryakov 2009-03-04 10:48:52 PST
The problem seems to be that layout is not performed for the select element. InlineTextBox::m_len is only set once (to the length of first option), so random bytes are used for other options:

    TextRun textRun(textRenderer()->text()->characters() + m_start, m_len, textRenderer()->allowTabs(), textPos(), m_toAdd, direction() == RTL, m_dirOverride || styleToUse->visuallyOrdered());

Comment 13 Alexey Proskuryakov 2010-01-29 16:52:45 PST
I cannot reproduce this with ToT.
Comment 14 James Wheare 2010-01-29 17:27:59 PST
What's ToT? I tried to Google it, I really did.
Comment 15 Alexey Proskuryakov 2010-01-29 17:30:04 PST
Tip of tree - a recent local build. This is usually close in behavior to a nightly build that one can get from <http://nightly.webkit.org>