Closed Bug 1041682 Opened 10 years ago Closed 6 years ago

[FxOS] Citibank Taiwan website shows the blank page

Categories

(Web Compatibility :: Site Reports, defect, P5)

Firefox 30
ARM
Gonk (Firefox OS)
defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: whsu, Unassigned)

References

()

Details

(Whiteboard: [1.4-dolphin-test-run-2] [country-tw] [contactready])

Attachments

(1 file)

Attached image 2014-07-27-18-53-34.png
* Description: Visiting the Citibank Taiwan website, you will see the browser only shows a blank page. It also can be reproduced on latest v2.0 build (flame) Attach the screenshot. (2014-07-27-18-53-34) * Reproduction steps: 1. Launch the browser 2. Input the following address on the URL bar - http://www.citibank.com.tw 3. Tap enter key * Expected result: You can visit Citibank Taiwan website via browser app * Actual result: Browser app shows a blank page * Reproduction build: V1.4 (Dolphin) - Gaia 621d152f89347c79619aa909ad62cc2ac9d3ab5b - Gecko 8d1beb4aa6f463361e08c94fb5763b37967f70c3 - BuildID 20140721185338 - Version 30.0
blocking-b2g: --- → 2.1?
Whiteboard: [1.4-dolphin-test-run-2]
William - Why do you think this is a Gaia::Browser bug? From my perspective, this looks more likely to be a site issue, since the issue is present across multiple releases (1.4 & 2.0) & involves a site-specific problem. If that's the case, then I'd argue that we should move this bug into the TE --> mobile component & remove the blocking nomination, since we typically don't block on site issues, as they are not directly related to gaia/gecko code.
Flags: needinfo?(whsu)
(In reply to Jason Smith [:jsmith] from comment #1) > William - Why do you think this is a Gaia::Browser bug? From my perspective, > this looks more likely to be a site issue, since the issue is present across > multiple releases (1.4 & 2.0) & involves a site-specific problem. If that's > the case, then I'd argue that we should move this bug into the TE --> mobile > component & remove the blocking nomination, since we typically don't block > on site issues, as they are not directly related to gaia/gecko code. Agree! Thanks for the suggestion! :)
blocking-b2g: 2.1? → ---
Component: Gaia::Browser → Mobile
Flags: needinfo?(whsu)
Product: Firefox OS → Tech Evangelism
Summary: [v2.0-Flame/v1.4-Dolphin] Citibank Taiwan website shows the blank page → [FxOS] Citibank Taiwan website shows the blank page
Version: unspecified → Firefox 30
tldr: It might not be a Tech Evangelism issue, it might be. It needs further analysis. Some findings: Once the URL has been entered http://www.citibank.com.tw/ the user (be on desktop or mobile) is being redirected to http://www.citibank.com.tw/sim/index.htm Firefox for Android receives the mobile content. Firefox for Desktop receives the desktop content. Faking the UA on desktop to be Firefox OS is working, we receive the mobile content. But it seems on the real Firefox OS device we receive the desktop content, there's a VISA card displayed only and it is scrollable. The Web site is using zepto.js That said there is something fishy. In the header there is a <noscript> <style type='text/css'> body {display:none} </style> </noscript> <style> html { visibility:hidden; } </style> <script> if( self == top){ document.documentElement.style.visibility='visible'; }else{ top.location = self.location; } </script> But not sure why. In SC_code1.js, there is a giant piece of JavaScript which includes elements about visibility change and which is constrained in a string, not sure why. I wonder why it works on Desktop and not on Mobile? Constrains about variable, another parameter? Kind of weird. I tried to isolate the part but it's not entirely related. s.mpc = function (m, a) { var s = this, c, l, n, v; v = s.d.visibilityState; if (!v) v = s.d.webkitVisibilityState; if (v && v == 'prerender') { if (!s.mpq) { s.mpq = new Array; l = s.sp('webkitvisibilitychange,visibilitychange', ','); for (n = 0; n < l.length; n++) { s.d.addEventListener(l[n], new Function(var s = s_c_il['+s._in+'], c, v; v = s.d.visibilityState; if (!v) v = s.d.webkitVisibilityState; if (s.mpq && v == 'visible') { while (s.mpq.length > 0) { c = s.mpq.shift(); s[c.m].apply(s, c.a) } s.mpq = 0 }), false) } } c = new Object; c.m = m; c.a = a; s.mpq.push(c); return 1 } return 0 }; It is client side related and not server side.
Flags: needinfo?(miket)
Flags: needinfo?(hsteen)
Whiteboard: [1.4-dolphin-test-run-2] → [1.4-dolphin-test-run-2] [country-tw] [js]
> <style> > html { visibility:hidden; } > </style> This stuff is added for "clickjacking" defense - i.e. if you try to include the Citibank site in a very small IFRAME and try to get users to "click" on one of its buttons believing they are clicking on something entirely different, the attack won't work because the Citibank page will be invisible.
Flags: needinfo?(hsteen)
Hah - gotcha! <meta name="viewport" content="width=device-width,initial-scale=0.0,minimum-scale=1.0,maximum-scale=0.0" /> Initial scale is 0.0? Oh well, let's scale all the content down to be infinitely small! (Except some random images that probably happen to be in IFRAMEs with documents without this viewport tag or something??)
Flags: needinfo?(miket)
Whiteboard: [1.4-dolphin-test-run-2] [country-tw] [js] → [1.4-dolphin-test-run-2] [country-tw] [contactready]
Priority: -- → P5
I don't think we are going to work on this anymore. Closing.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Product: Tech Evangelism → Web Compatibility
Component: Mobile → Site Reports
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: