[Webkit-unassigned] [Bug 48483] New: Get rid of ResourceRequestBase::m_targetType

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Oct 27 16:39:09 PDT 2010


https://bugs.webkit.org/show_bug.cgi?id=48483

           Summary: Get rid of ResourceRequestBase::m_targetType
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Page Loading
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: ap at webkit.org


Keeping the knowledge of Web platform concepts (main frame? subframe?) in ResourceRequest is a layering violation. The only valid use for target type that I know is centralized request prioritization on platforms that have a separate process for network loading.

I thought that the initial step could be to move it behind #if PLATFORM(CHROMIUM). But Joe explained that Blackberry is also using a separate process.

My biggest concern is with attempts to use ResourceRequest::m_targetType for anything but passing priority to network loading back-end (as we've seen in bug 27165). Keeping it as a cross-platform data member will undoubtedly keep causing confusion.

I can think of two things to do to improve the situation.

1. Make the priority values passed to loader process Web-agnostic to address layering violations. Arguments can be made either way, but to me, it seems more of a WebCore job to set relative priorities for various request types. Otherwise, we'd need to update loaders (separate projects living in different repositories) simultaneously once a new target type appears in the Web platform.

2. Pass the priority outside of ResourceRequest (as a separate argument). Or alternatively, just make sure to reset it in Mac WebKit code after re-creating ResourceRequest from NSResourceRequest - it's not like a delegate call will change top frame resource into a subframe resource!

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list