Bug 190741 - Use consistent type for resource load identifier
Summary: Use consistent type for resource load identifier
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Keith Rollin
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2018-10-18 17:05 PDT by Keith Rollin
Modified: 2021-11-01 12:53 PDT (History)
8 users (show)

See Also:


Attachments
Patch (110.32 KB, patch)
2018-10-19 09:03 PDT, Keith Rollin
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Keith Rollin 2018-10-18 17:05:53 PDT
Variables and parameters used to hold resource load identifiers are variously defined as ResourceLoadIdentifier, uint64_t, or unsigned long. Standardize all of these on ResourceLoadIdentifier. At the same time, define ResourceLoadIdentifier in terms of WTF::ObjectIdentifier to address type-safety and conversion issue.
Comment 1 Radar WebKit Bug Importer 2018-10-18 17:06:17 PDT
<rdar://problem/45390318>
Comment 2 Keith Rollin 2018-10-19 09:03:57 PDT
Created attachment 352787 [details]
Patch
Comment 3 EWS Watchlist 2018-10-19 09:06:08 PDT
Attachment 352787 [details] did not pass style-queue:


ERROR: Source/WebCore/loader/LoaderStrategy.h:94:  Inline functions should not be in classes annotated with WEBCORE_EXPORT. Remove the macro from the class and apply it to each appropriate method, or move the inline function definition out-of-line.  [build/webcore_export] [4]
Total errors found: 1 in 28 files


If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 4 Keith Rollin 2018-10-19 09:50:44 PDT
That check-webkit-style message is benign in this case.
Comment 5 Chris Dumez 2018-10-22 09:14:14 PDT
Comment on attachment 352787 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=352787&action=review

Looks like it's going to be great but I do have a few questions.

> Source/WebCore/inspector/agents/InspectorNetworkAgent.cpp:445
> +            auto response = platformStrategies()->loaderStrategy()->responseFromResourceLoadIdentifier(makeResourceLoadIdentifier(identifier));

Why is this method taking in an unsigned long instead of a ResourceLoadIdentifier?

> Source/WebCore/loader/FrameLoader.cpp:2994
> +            platformStrategies()->loaderStrategy()->loadResourceSynchronously(*this, makeResourceLoadIdentifier(identifier), newRequest, clientCredentialPolicy, options, originalRequestHeaders, error, response, buffer);

Seems like requestFromDelegate() should return a ResourceLoadIdentifier?

> Source/WebCore/loader/ResourceLoadIdentifier.h:42
> +    return generateObjectIdentifier<ResourceLoadIdentifierType>();

We should ASSERT this is always called from the main thread since you're using the non-thread safe variant.

> Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:342
> +    auto completionHandler = [connection = m_connection.copyRef(), identifier = loadParameters.identifier.toUInt64()] (const ResourceError& error, const ResourceResponse& response) {

Seems like we should pipe through the ResourceLoadIdentifier? Why going back to a uint64_t now?

> Source/WebKit/NetworkProcess/NetworkResourceLoader.cpp:969
> +    return value ? String::number(value.value().toUInt64()) : String("None");

"None"_s is slightly more efficient iirc since you're constructing from a string literal.

Also, value->toUInt64() is shorter.

> Source/WebKit/NetworkProcess/NetworkResourceLoader.cpp:1083
> +    send(Messages::WebPage::AddConsoleMessage { m_parameters.webFrameID,  messageSource, messageLevel, message, identifier().toUInt64() }, m_parameters.webPageID);

Why convert back to a uint64_t here?

> Source/WebKit/WebProcess/Network/WebLoaderStrategy.cpp:252
> +    WebCore::ResourceLoadIdentifier identifier = WebCore::makeResourceLoadIdentifier(resourceLoader.identifier());

I find it troubling that resourceLoader.identifier() does not return a ResourceLoadIdentifier. Why is that?
Comment 6 Keith Rollin 2019-04-08 17:14:32 PDT
Making this change turns out to have extensive implications. The ResourceLoadIdentifier type propagates itself all throughout the sources, and even starts to get into areas where it's not clear if are actually dealing with resource load identifiers. Better just to leave things the way they are for now.
Comment 7 Alex Christensen 2021-11-01 12:53:56 PDT
Comment on attachment 352787 [details]
Patch

This has been requesting review for more than one year.  If this is still needed, please rebase and re-request review.