| Summary: | REGRESSION(r173188): Text inserted when trying to delete a word from the Twitter message box | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Alberto Garcia <berto> | ||||||||
| Component: | JavaScriptCore | Assignee: | Andreas Kling <kling> | ||||||||
| Status: | RESOLVED FIXED | ||||||||||
| Severity: | Normal | CC: | ap, bugzilla, cgarcia, commit-queue, ggaren, gustavo, kling, mcatanzaro | ||||||||
| Priority: | P2 | Keywords: | Gtk, Regression | ||||||||
| Version: | 528+ (Nightly build) | ||||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Alberto Garcia
2014-11-27 06:21:22 PST
This is very slippery, but I managed to reproduce it once so far when using Safari 7.1 user-agent string. Will try to debug. If you've seen any assertions when this happens, that would be very helpful. Hey, I just tried a debug build and I cannot see any assertions or any other messages. In my case I can reproduce it easily in 100% of the cases, here's my user agent in case it's relevant: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/601.1 (KHTML, like Gecko) Version/8.0 Safari/601.1 I still can't reproduce this reliably. The times I did succeed it seemed to happen when transitioning between empty/nonempty text field. Is that the case for you as well? Could you describe the repro steps in detail just in case I'm misinterpreting your description? Sure, here they are: - Open the MiniBrowser - Go to https://twitter.com/ and log in - On top of the timeline there's a box with the "What's happening?" message. - Click there, the message disappears so you can enter your tweet. - Type "foo bar baz". - Press backspace a few times, it will start deleting the letters one by one but at some point the whole text is replaced by " #document ". (In reply to comment #0) > It looks like > this was a regression introduced in r173188 and it still happens now > (r176549). I can still revert the change cleanly and it seems to fix the > problem. Hey Carlos, this would probably be a good one to revert for the 2.6 branch. This happens a lot in GTK+ in both Twitter and Etherpads, but it is not just related to deleting, it may happen at any point while typing text. Unfortunately I couldn't find a simple way to reproduce it reliably. FYI I am actively working on this bug. Created attachment 242587 [details]
Patch
Comment on attachment 242587 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=242587&action=review r=me > Source/JavaScriptCore/runtime/JSString.cpp:447 > + // NOTE: If the StringImpl* key no longer matches the StringImpl* inside the cached JSString, > + // it's because the JSString had its StringImpl replaced with an atomic version. > + // This causes trouble when a new StringImpl gets allocated at exactly the same address > + // as a previously deleted one. > + // Leaving stale keys in the string cache is otherwise safe, so we manage this issue > + // here on the slow path instead of removing things from the cache on the hot path. I think I would simplify this comment and just say something like: A JSString is allowed to change its underlying StringImpl*, so we need to double-check that the JSString in the cache still matches the StringImpl* in the cache. No need to restrict the definition of when JSString might change itself. It do what it want. Seems like we need to do something about our other 2 StringImpl=>JSString maps, since they are technically not safe. Created attachment 242593 [details]
Patch II
Less scary solution.
Created attachment 242594 [details]
Patch II
Comment on attachment 242594 [details]
Patch II
r=me -- even better!
Comment on attachment 242594 [details] Patch II Clearing flags on attachment: 242594 Committed r176824: <http://trac.webkit.org/changeset/176824> All reviewed patches have been landed. Closing bug. |