Summary: | Remove a few more uses of the terms black/white list | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Darin Adler <darin> | ||||||||
Component: | New Bugs | Assignee: | Darin Adler <darin> | ||||||||
Status: | RESOLVED FIXED | ||||||||||
Severity: | Normal | CC: | achristensen, bdakin, benjamin, cdumez, cmarcelo, ews-watchlist, webkit-bug-importer | ||||||||
Priority: | P2 | Keywords: | InRadar | ||||||||
Version: | WebKit Nightly Build | ||||||||||
Hardware: | Unspecified | ||||||||||
OS: | Unspecified | ||||||||||
See Also: | https://bugs.webkit.org/show_bug.cgi?id=213084 | ||||||||||
Bug Depends on: | |||||||||||
Bug Blocks: | 213092 | ||||||||||
Attachments: |
|
Description
Darin Adler
2020-07-15 12:34:14 PDT
Created attachment 404375 [details]
Patch
Comment on attachment 404375 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=404375&action=review Looks good except the part that adds another file read. > Source/WTF/wtf/URLHelpers.cpp:61 > +// Cocoa has an implementation that read this from a file in /Library or ~/Library. reads > Source/WTF/wtf/cocoa/NSURLExtras.mm:85 > + // FIXME: Remove this at some point after checking that no one is depending on it. I've tried to remove this in the past and was informed that it exists only for third parties and we have no way of checking if they still use it. There's also an optimization for it in Foundation, which we should rename at the same time. I think we should do that instead of checking both filenames, which will significantly adversely affect startup time of many things. Comment on attachment 404375 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=404375&action=review >> Source/WTF/wtf/cocoa/NSURLExtras.mm:85 >> + // FIXME: Remove this at some point after checking that no one is depending on it. > > I've tried to remove this in the past and was informed that it exists only for third parties and we have no way of checking if they still use it. There's also an optimization for it in Foundation, which we should rename at the same time. I think we should do that instead of checking both filenames, which will significantly adversely affect startup time of many things. Yes, I am familiar with how this was originally used. I’m the person who added this in the first place. But I don’t know anything about this optimization in Foundation. I’ll leave this part out of the patch based on the FUD. Created attachment 404378 [details]
Patch
Let's just do it now. I filed rdar://problem/65622670 Comment on attachment 404378 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=404378&action=review > Source/WTF/wtf/URLHelpers.cpp:61 > +// Cocoa has an implementation that read this from a file in /Library or ~/Library. Oops, forgot to fix "read this" to "reads this". Created attachment 404391 [details]
Patch
Committed r264423: <https://trac.webkit.org/changeset/264423> Comment on attachment 404375 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=404375&action=review >>> Source/WTF/wtf/cocoa/NSURLExtras.mm:85 >>> + // FIXME: Remove this at some point after checking that no one is depending on it. >> >> I've tried to remove this in the past and was informed that it exists only for third parties and we have no way of checking if they still use it. There's also an optimization for it in Foundation, which we should rename at the same time. I think we should do that instead of checking both filenames, which will significantly adversely affect startup time of many things. > > Yes, I am familiar with how this was originally used. I’m the person who added this in the first place. > > But I don’t know anything about this optimization in Foundation. I’ll leave this part out of the patch based on the FUD. I was wrong about the optimization in Foundation. That is just an optimization for the instantiation of an NSString, not in reading the file. That's not important to change at the same time as this. I think it’s fine to either remove the feature entirely, or change the name now, or add support for both names now to lay the ground work for removing the old name later. But I suggest we *not* use this bug to track any of those changes. This one should be left as is. I think we should remove it in a separate patch, probably after the next branch. |