Steps to reproduce
1. Log in to Last.fm. http://www.last.fm/login
Test account if needed:
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.
* 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.
This looks fixed in the latest nightly. I'd like to know the cause of this bug so I can workaround it though.
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.
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.
Created attachment 27446 [details]
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.
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.
I suppose this is probably the best I'll get for looking up revision numbers corresponding to releases:
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.
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.
More info including possible workarounds:
This behaviour is still happening in the Safari 4 public beta. Is that using an older version of webkit?
I can reproduce this with a local debug build of r41380 (using the reduction at <http://james.wheare.org/stuff/bugs/safari/fixedselect>).
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());
I cannot reproduce this with ToT.
What's ToT? I tried to Google it, I really did.
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>