1282887 - Failing NavigationTests#testBackForwardNavigationRestoresMobileOrDesktopSite

Status: RESOLVED FIXED

(Firefox for iOS :: Build & Test, defect)

Description

[Brian Nicholson (:bnicholson)]

testBackForwardNavigationRestoresMobileOrDesktopSite triggers Request Desktop Site, which loads the same page by firing loadRequest with a new NSURLRequest. As of bug 1263627, any localhost requests will fail unless those requests are PrivilegedRequests. That means we're failing now for any situations where we change UAs for localhost URLs.

Not a practical concern since changing the UA for our local pages will have no effect anyway, but fixing it makes the test pass.

Comment 1

[Brian Nicholson (:bnicholson)]

Attachment: Link to Github pull-request: https://github.com/mozilla/firefox-ios/pull/1955

Comment 2

[Emily Toop (:fluffyemily)]

Attachment: Screen Shot 2016-06-29 at 15.05.45.png

The patch causes the test to pass but I think highlights an error in the test.

The test ensures that if we request desktop site on one item in the back forward list, it does not change the menu options when moving to another item. However when replicating this test on real sites, the test does not pass (on Simulator, iPhone 6, iOS 9.3 & iOS 9.2)

STR

Open a new tab
Navigate to facebook.com (resolves to m.facebook.com)
Navigate to twitter.com (resolves to mobile.twitter.com)
Long Press on Reload button
Select Request Desktop Site
URL updates to twitter.com
press back arrow
URL is still m.facebook.com
Long Press on Reload button

Expected:

Long press action is Request Desktop Site

Actual:

Long press action is Request Mobile Site

Comment 3

[Brian Nicholson (:bnicholson)]

Interesting find! Digging in, here's what I found:
* When going back, we call restoreSpoofedUserAgentIfRequired [1], which pulls the User-Agent HTTP header from the request we're using to go back.
* For most sites, WKWebView (correctly!) remembers the UA used to load the page when going back, and the User-Agent field will be "" unless that page was loaded with RDS.
* For some inexplicable reason, the Facebook/Twitter pairing causes `newRequest.valueForHTTPHeaderField("User-Agent")` at [1] to be set to the desktop UA when going back to Facebook. Seems like an iOS bug; it doesn't make sense that the UA header from one site would be carried over to a separate request.

This is a separate issue, so I filed bug 1283210 with the above info.

[1] https://github.com/mozilla/firefox-ios/blob/50ae3ec15989aaa620fcb8d660e293c6e579deff/Client/Frontend/Browser/BrowserViewController.swift#L2264
[2] https://github.com/mozilla/firefox-ios/blob/50ae3ec15989aaa620fcb8d660e293c6e579deff/Client/Frontend/Browser/BrowserViewController.swift#L1088

Comment 4

[Emily Toop (:fluffyemily)]

Comment on attachment 8766024 [details] [review]
Link to Github pull-request: https://github.com/mozilla/firefox-ios/pull/1955

Cool, if this is an edge case caused by certain site combos cool. I was just unlucky in the 2 sites I picked to test this IRL then. I was, understandably, concerned that our test was testing the wrong thing if I could replicate it on the browser directly.

Comment 5

[Brian Nicholson (:bnicholson)]

https://github.com/mozilla/firefox-ios/commit/d97e70304e59f8243c2787ed2d4432e224b4b8a3