Apache Cordova
  1. Apache Cordova
  2. CB-2225

User-Agent changes in the CordovaWebView after using InAppBrowser

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.4.0
    • Component/s: iOS
    • Labels:
      None

      Description

      See CB-2102.

      Attached www-cb-2102.zip which I tested with Cordova 2.3.0.

      Repro:
      1. On the main index.html, touch the "UserAgent" button, observe that the UA has a numbered suffix (correct)
      2. Touch the "About" link to go to the About page
      3. On the About page, touch the "UserAgent" button, observe that the UA has a numbered suffix (correct, it's the same as in (1))
      4. Touch the "English" link, this will load a PDF in the InAppBrowser
      5. Touch the "Done" button in the InAppBrowser to dismiss it
      6. Now you are back to the "About" page, touch the "UserAgent" button again, and note that the UA is not the same as expected in (3)

      1. www-cb-2102.zip
        4.27 MB
        Shazron Abdullah

        Activity

        Hide
        Andrew Grieve added a comment -

        Did some research with this:

        -Does the UA always for each PDF open, or only the first PDF load
        -Only the first time

        -Can we load pdfs in an iframe, does this trigger the bug?
        -PDFs do load in iframes, but don't trigger the bug.

        -Can we detect PDF loads?
        -They have a nil URL in their request object when webViewDidStartLoad is called, but not webViewDidFinishLoad nor shouldLoad
        -It's likely that we could identify a PDF in our NSURLProtocol handler, but only if we proxy the request

        So..., some possible Solutions:

        #1 - After loading first page, load a background UIWebView with a PDF (maybe even use data URL)

        #2 - Detect PDF load (via the nil URL), and let it load without changing the user-agent.

        • Make sure the load works by temporarily adding the URL to the container's whitelist
        • If the user tries to navigate anywhere else with the UIWebView, close it and make a new one
        • This method still messes things up if there are more than one active CDV webviews

        #3 - Block all PDF loads

        • Not sure this is easy to do without proxying every request, which has other side-effects

        I think the first option is probably the best for starters, it's possible the the UA bug is triggered from some sub-system being loaded the first time a PDF is loaded, and so doing it every time will cause the app to use more memory than it requires. Maybe we could have a user-pref that would allow the bug work-around to be disabled if they are sure that their app can't be used to navigate to a PDF, or if they don't use a whitelist anyways.

        Show
        Andrew Grieve added a comment - Did some research with this: -Does the UA always for each PDF open, or only the first PDF load -Only the first time -Can we load pdfs in an iframe, does this trigger the bug? -PDFs do load in iframes, but don't trigger the bug. -Can we detect PDF loads? -They have a nil URL in their request object when webViewDidStartLoad is called, but not webViewDidFinishLoad nor shouldLoad -It's likely that we could identify a PDF in our NSURLProtocol handler, but only if we proxy the request So..., some possible Solutions: #1 - After loading first page, load a background UIWebView with a PDF (maybe even use data URL) #2 - Detect PDF load (via the nil URL), and let it load without changing the user-agent. Make sure the load works by temporarily adding the URL to the container's whitelist If the user tries to navigate anywhere else with the UIWebView, close it and make a new one This method still messes things up if there are more than one active CDV webviews #3 - Block all PDF loads Not sure this is easy to do without proxying every request, which has other side-effects I think the first option is probably the best for starters, it's possible the the UA bug is triggered from some sub-system being loaded the first time a PDF is loaded, and so doing it every time will cause the app to use more memory than it requires. Maybe we could have a user-pref that would allow the bug work-around to be disabled if they are sure that their app can't be used to navigate to a PDF, or if they don't use a whitelist anyways.
        Hide
        Andrew Grieve added a comment -

        I went with option #2 for now.

        Fix commit:
        https://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=commit;h=07a223ee65add7e5e6ff108a77fbc684dad79914

        There's some notes in CDVInAppBrowser about the work-around. Here they are:
        This work-around makes the following assumptions:
        1. The app has only a single Cordova Webview. If not, then the app should
        take it upon themselves to load a PDF in the background as a part of
        their start-up flow.
        2. That the PDF does not require any additional network requests. We change
        the user-agent here back to that of the CDVViewController, so requests
        from it must pass through its white-list. This does break PDFs that
        contain links to other remote PDF/websites.

        Show
        Andrew Grieve added a comment - I went with option #2 for now. Fix commit: https://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=commit;h=07a223ee65add7e5e6ff108a77fbc684dad79914 There's some notes in CDVInAppBrowser about the work-around. Here they are: This work-around makes the following assumptions: 1. The app has only a single Cordova Webview. If not, then the app should take it upon themselves to load a PDF in the background as a part of their start-up flow. 2. That the PDF does not require any additional network requests. We change the user-agent here back to that of the CDVViewController, so requests from it must pass through its white-list. This does break PDFs that contain links to other remote PDF/websites.
        Hide
        Andrew Grieve added a comment -

        The first fix wasn't working properly (was applying the PDF "fix" to all requests). Here's the follow-up fix:

        https://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=commit;h=b8f7515bdb840be4619ecee2f6ed71a0a57dbad1

        Show
        Andrew Grieve added a comment - The first fix wasn't working properly (was applying the PDF "fix" to all requests). Here's the follow-up fix: https://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=commit;h=b8f7515bdb840be4619ecee2f6ed71a0a57dbad1

          People

          • Assignee:
            Andrew Grieve
            Reporter:
            Shazron Abdullah
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development