1231416 - If the UA string is not TV, redirect (and vice versa)

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::TV, defect, P3)

Description

[David Durst [:ddurst]]

If the UA string is not TV ("Mozilla/5.0 (TV; rv:44.0) Gecko/44.0 Firefox/44.0", according to bug 1015872), then:
- request for marketplace.firefox.com/tv redirects to marketplace.firefox.com

If the UA string is TV, then:
- request for marketplace.firefox.com redirects to marketplace.firefox.com/tv

Comment 1

[Evelyn Hung]

:ddurst, may I know who will work on this?

Comment 2

[David Durst [:ddurst]]

(In reply to Evelyn Hung [:evelyn] from comment #1)
> :ddurst, may I know who will work on this?

We're intentionally holding off on this until bug 1231545 is done, because without the ability to change the UA in the simulator, you would be unable to access the TV Marketplace on anything but a real TV.

Once bug 1231545 is closed, we can move forward with this.

Comment 3

[Evelyn Hung]

(In reply to David Durst [:ddurst] from comment #2)
> (In reply to Evelyn Hung [:evelyn] from comment #1)
> > :ddurst, may I know who will work on this?
> 
> We're intentionally holding off on this until bug 1231545 is done, because
> without the ability to change the UA in the simulator, you would be unable
> to access the TV Marketplace on anything but a real TV.
> 
> Once bug 1231545 is closed, we can move forward with this.

I see, but no one is working on bug 1231545. we should workaround this testing issue.

SC, do we have any way to set UA in the code manually?

Comment 4

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

I already introduced a UA device type configuration for simulator in https://dxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/nsHttpHandler.cpp#783
It's weird that it doesn't work on the current release of TV simulator.

keep ni? flag for me to check this issue.

Comment 5

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

Wrong compile option for the UA string customization was used. Instead of "FXOS_SIMULATOR", I should use "MOZ_MULET" in nsHttpHandler.cpp. In addition, MOZ_UA_OS_AGNOSTIC=1 should be added into b2g/dev/confvars.sh for generating the same UA string as the real device.

Comment 6

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

Attachment: MozReview Request: Bug 1231416 - fix Mulet UA string generation rule. r=fabrice.

Review commit: https://reviewboard.mozilla.org/r/35087/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/35087/

Comment 7

[[:fabrice] Fabrice Desré]

Comment on attachment 8719736 [details]
MozReview Request: Bug 1231416 - fix Mulet UA string generation rule. r=fabrice.

https://reviewboard.mozilla.org/r/35087/#review31775

lgtm

Comment 8

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/51ec2c3783c7

Comment 9

[Gregor Wagner [:gwagner]]

This caused a few perma mochitest failures on mulet: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=51ec2c3783c7&exclusion_profile=false&filter-tier=1&filter-tier=2&filter-tier=3&filter-searchStr=Mulet

Comment 10

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/51ec2c3783c7

Comment 11

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

hmm...I discovered that several test cases are using UA string spoofing to detect the platform after I turned on MOZ_UA_OS_AGNOSTIC for Mulet build.

[affected test cases]
dom/alarm/test/test_alarm_add_data.html
dom/alarm/test/test_alarm_add_respectTimezone.html
dom/alarm/test/test_alarm_remove.html
dom/alarm/test/test_bug1015540.html
dom/alarm/test/test_bug1037079.html
dom/alarm/test/test_bug1090896.html
dom/messages/test/test_bug_993732.html
dom/permission/tests/test_embed-apps.html
dom/canvas/test/crossorigin/test_video_crossorigin.html
dom/canvas/test/test_drawWindow.html
gfx/layers/apz/test/mochitest/test_bug1151667.html
image/test/reftest/pngsuite-ancillary/ccwn2c08.html

[haven't figured out]
system/test/unit/update_manager_test.js
dom/tests/mochitest/fetch/test_fetch_cors.html
dom/tests/mochitest/fetch/test_fetch_cors_sw_empty_reroute.html
dom/tests/mochitest/fetch/test_request_sw_reroute.html

submit a try run for confirmation: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f3e612a06575

Comment 12

[David Durst [:ddurst]]

This bug was supposed to capture the actual redirection work, not the UA customization (that's bug 1231545). Am I mistaken in reading these last few comments as though we're talking about the ability to change the UA (and not a redirection based on said change in the simulator)?

Comment 13

[Evelyn Hung]

[Blocking Requested - why for this release]: it's better to fix this issue so people won't go the wrong Marketplace site.

Comment 14

[Evelyn Hung]

(In reply to David Durst [:ddurst] from comment #12)
> This bug was supposed to capture the actual redirection work, not the UA
> customization (that's bug 1231545). Am I mistaken in reading these last few
> comments as though we're talking about the ability to change the UA (and not
> a redirection based on said change in the simulator)?

You are right, this bug is for marketplace server side redirect logic. So who should be bug assignee?

Comment 15

[Evelyn Hung]

Luke, could you help check out what will happen if the user navigate to the phone's marketplace on a real TV? Will the user be able to install any app?

Comment 16

[Luke Chang [:lchang] (inactive)]

It shows desktop version when navigating "marketplace.firefox.com" in TV browser. Users can install apps with prompt triggered, and the installed app shows in the app deck as usual.

Comment 17

[Luke Chang [:lchang] (inactive)]

Please see the screenshots here: https://goo.gl/JQ4Juo

Comment 18

[David Durst [:ddurst]]

Does the installed app work?

I imagine there could be inaccuracies in the feature compatibility of apps on TV, since we aren't (afaik) checking that they be compatible -- mostly because TV was only set up to get websites, not apps.

NI ashort to verify that we do not check feature compatibility in the API response for TV (the way we do for apps, that is).

Comment 19

[David Durst [:ddurst]]

I should be more clear: the API response on m.f.c when requested from a TV (not /tv).

Comment 20

[Allen Short [:ashort]]

We don't do any feature detection. TV uses website links not apps, so there's no manifest with features etc.

Comment 21

[David Durst [:ddurst]]

So the installed app *might* work, or it might not.

Comment 22

[Evelyn Hung]

Yes, app installation works, and we will see a phone app running on a TV.

Comment 23

[Evelyn Hung]

It seems not a 2.5 blocker, but anyone's help from marketplace team is welcome. :)

Comment 24

[David Durst [:ddurst]]

There's a PR up for this, on the fireplace side, anyway: https://github.com/mozilla/fireplace/pull/1609

There would need to be an analogous one on the client side, of course.

Comment 25

[BMO Automation]

Firefox OS is not being worked on