Summary: | Replace more uses of DeprecatedString with String | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Eric Seidel (no email) <eric> | ||||||
Component: | WebKit Misc. | Assignee: | Eric Seidel (no email) <eric> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Normal | ||||||||
Priority: | P4 | ||||||||
Version: | 420+ | ||||||||
Hardware: | Mac | ||||||||
OS: | OS X 10.4 | ||||||||
Attachments: |
|
Description
Eric Seidel (no email)
2006-03-22 01:45:38 PST
Created attachment 7227 [details]
Replace more uses of DeprecatedString with String
Created attachment 7228 [details]
Remove a few more DeprecatedString uses while I'm at it...
Comment on attachment 7228 [details]
Remove a few more DeprecatedString uses while I'm at it...
+ if (s.isEmpty())
+ return String(cs);
You don't need all these isEmpty checks. The String + operator already handles them; an additional check doesn't add value.
The AccessibilityObjectCache changes are going to collide with my near-complete rewrite of that file due to fixing it for Garbage Collection (and yes, I had removed use of DeprecatedString).
I'm not sure about the "get values directly from settings" change. It's a nice simplification. But it means that some settings that used to stay the same until location change will now be "live". That means you could start loading a page with JavaScript disabled and then later have it enabled or vice versa. I believe that can lead to problems, although I'm not certain. Since you're changing the semantics you will need to test.
r=me, assuming you test the settings change in Frame
I made darin's suggested modifications and landed. |