STR:

• Log into rogers.com
• Navigate to https://www.rogers.com/consumer/self-serve/view-bill

The blocked iframe is https://www.rogers.com/consumer/self-serve/assets/html/viewInvoiceDetail.html

The viewInvoiceDetail.html frame seems to be setting location.href to https://www.rogers.com/consumer/self-serve/#/bill/... which causes the X-Frame-Options error

The stack for that looks something like:

goToView https://www.rogers.com/bbapp/bbapi.js?v=1:96:20
displayBill https://www.rogers.com/bbapp/bbapi.js?v=1:41:17
BBAPI.displayBill https://www.rogers.com/bbapp/bbapi.js?v=1:245:27
getBillAndDisplay https://www.rogers.com/consumer/self-serve/assets/scripts/bbIframeLoad.js?v=1:245:13
success https://www.rogers.com/consumer/self-serve/assets/scripts/bbIframeLoad.js?v=1:279:30

goToView looks like:

      function goToView(InvoiceId, route, param) {
        var link = '#/' + route + '/' + InvoiceId;
        if (param !== undefined) {
          link = link + '?' + param;
        }
        window.location.href = link;
      }

It's setting location.href to something like #/bill/... while location.href is currently like: https://www.rogers.com/consumer/self-serve/assets/html/viewInvoiceDetail.html?....
In Chrome location.href ends up as https://www.rogers.com/consumer/self-serve/assets/html/viewInvoiceDetail.html?...#/bill/...
where as in Firefox it ends up as https://www.rogers.com/consumer/self-serve/#/bill/...

LocationBase::GetSourceBaseURL() is returning: https://www.rogers.com/consumer/self-serve/ which is surprising.

gdb or pernosco should work pretty well for that I imagine

Given that not everyone has access to that website, who can help provide a pernosco session that we can share (internally)?

I'm trying to get a pernosco session.

I have a pernosco session

print xpc::WindowGlobalOrNull(aCallback->mCallbackGlobal.ptr)->mDoc.mRawPtr->mDocumentURI.mRawPtr->mSpec:
https://www.rogers.com/consumer/self-serve/assets/html/viewInvoiceDetail.html

print xpc::WindowGlobalOrNull(aCallback->mCallback.ptr)->mDoc.mRawPtr->mDocumentURI.mRawPtr->mSpec
https://www.rogers.com/consumer/self-serve/view-bill

It seems like we're getting a callback that has a different global and that's confusing things.

Blocking https://www.rogers.com/resources/86041257f86af355de353679925a3b706c8faa4011e32 fixes viewing the bills for me. That script looks to be a variant of the https://p11.techlab-cdn.com stuff that sets up hooks for all kinds of things. It was also causing a mess in bug 1988248.

XMLHttpRequest.prototype.open: Proxy in viewInvoiceDetail.html but I can't figure out how 86041257f86af355de353679925a3b706c8faa4011e32 is accomplishing it. It seems to be set that way before any script runs in viewInvoiceDetail.html

https://crisal.io/tmp/rogers/ reproduces the behavior difference. We still don't know why chrome doesn't end up with a proxy, and if you change the iframe to be appended with the .src set first, then Chrome also reproduces the issue...

Vincent, does comment 13 reproduce the issue with the patches from bug 543435 out of curiosity?

No, with the sync-about-blank patch, the page seems to behave as in Chromium. Specifically, clicking the button causes no visual change (FAIL is not shown) and the console shows

Adding iframe rogers:8:13
attempting navigation subframe.html:4:11
https://crisal.io/tmp/rogers/subframe.html subframe.html:11:13
https://crisal.io/tmp/rogers/subframe.html#foo

The hooks get installed by a function that looks like this:

            M(a, b) {
              El(a);
              Fl(a);
              {
                var c = this.G,
                d = af;
                wl(c, a);
                ta ? zl(a) : Al(a);
                for (var e = Ve.apply(d.Ra); ; ) try {
                  for (var f of e) xl(c, a, f);
                  break
                } catch (m) {
                }
                Sr(d.Xb, a);
                const k = Ve.apply(d.Ga);
                for (; ; ) try {
                  for (const m of k) {
                    const q = m.va,
                    u = a[m.J];
                    if (u) {
                      const v = !!u.prototype &&
                      u.prototype ||
                      (q === Za ? u : void 0);
                      if (v) {
                        const n = {};
                        ta &&
                        b &&
                        m.L &&
                        ug(a, q, v, n, m.L);
                        {
                          d = c;
                          e = a;
                          f = v;
                          var g = n,
                          l = m;
                          const p = l.va;
                          if (l.Jb) {
                            var h = l.Jb;
                            vd(d, e, f, p, 'setAttribute', h.Ia);
                            vd(d, e, f, p, 'setAttributeNS', h.La);
                            vd(d, e, f, p, 'setAttributeNode', h.Ja);
                            vd(d, e, f, p, 'setAttributeNodeNS', h.Ka)
                          }
                          const r = l.K[Symbol.iterator]();
                          for (; ; ) try {
                            for (const t of r) {
                              const Sa = t.Bb,
                              Xb = Qc(f, Sa);
                              Xb &&
                              (ul(d, f, Xb, p, t, e), t.Ib || t.Kb) &&
                              (g[Sa] = Xb)
                            }
                            break
                          } catch (t) {
                          }
                        }
                        Object.defineProperties(v, n)
                      }
                    }
                  }
                  break
                } catch (m) {
                }
                Oc &&
                Bl(a)
              }
              Cl(this.G, a);
              Ms(this.G, a);
              ql(a)
            }

Ok, so I think at this point the main theory is:

• They are hooking the proxy stuff on the iframe load. But they do only on one load event, so for the case where they insert the iframe, then they change source, Firefox fires only one load event (for the right page), but other browsers load both about:blank synchronously, and the right page, which doesn't get the hooks.

• If so, it seems this is mostly working by chance in Chrome and WebKit. They should probably either fix their hooks, or at the very least change the code from window.location.href = "#foo" to something like:

let url = new URL(window.location.href);
url.hash = "#foo"
window.location.href = url.href;

Can we contact them about that?

• The fact that window.location.href = "#foo" uses a totally different base URI seems extremely weird. I filed https://github.com/whatwg/html/issues/11852 about it.

Darn, we can't hook an intervention into location.href, because it's not JS-configurable/is locked (for security reasons). So the best we could probably do here with an intervention is re-write their script on-the-fly to do what Emilio suggests in comment 17. Emilio, which request/script has that location-changing code?

Olli do you know why / if it's intended we preserve the global on navigation from the initial about:blank? I guess it makes sense when the original about:blank gets replaced by another about:blank, but not in this case probably?

(In reply to Thomas Wisniewski [:twisniewski] from comment #19)

Emilio, which request/script has that location-changing code?

goToView() comes from https://www.rogers.com/bbapp/bbapi.js?v=1

Reusing the global means that one can add event listeners to window object (load listener for example) and then when same origin page loads there, the listener gets still called. That has been needed for example with window.open() case.

But vhilla and hsivonen have been dealing with the about:blank issues.

https://hg.mozilla.org/mozilla-central/rev/e01873dee848

(In reply to Emilio Cobos Álvarez [:emilio] from comment #20)

Olli do you know why / if it's intended we preserve the global on navigation from the initial about:blank? I guess it makes sense when the original about:blank gets replaced by another about:blank, but not in this case probably?

(In reply to Olli Pettay [:smaug][[email protected]] from comment #22)

Reusing the global means that one can add event listeners to window object (load listener for example) and then when same origin page loads there, the listener gets still called. That has been needed for example with window.open() case.

The relevant code is nsGlobalWindowOuter::WouldReuseInnerWindow https://searchfox.org/firefox-main/rev/e613f4df351a21871cfeadf7d5b4043ffad157b1/dom/base/nsGlobalWindowOuter.cpp#1715

It is intended, but due to out async about:blank (see bug 543435), there are some differences to other browsers.

Olli is right. I.e. code like this where one attaches the load listener to the transient blank document should receive the load event for the target url.

w = window.open("/test")
w.onload = console.log

If the URL would be about:blank and the code would synchronously kick off another navigation, this is where browsers differ regarding global reuse.

With the attached test case, srcset is set synchronously after binding the iframe. When the iframe is bound, no src implicitly means loading about:blank. So Gecko starts out with an initial blank document and starts loading about:blank but cancels that in favor of srcset, the latter leading to the navigation that reuses the global. Chrome immediately finishes loading about:blank and srcset leads to a second navigation, you'll see the onload handler runs twice.

firefox-release Uplift Approval Request

• User impact if declined: Rogers customers will see a broken iframe with "Firefox Can’t Open This Page" when trying to view their bills, rather than the billing info.
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: 1) Log in at https://www.rogers.com/

2. Visit https://www.rogers.com/consumer/self-serve/view-bill
3. Confirm that the billing info appears, rather than a broken iframe with "Firefox Can’t Open This Page".

• Risk associated with taking this patch: low
• Explanation of risk level: This only impacts the webcompat site interventions addon, and the rogers.com website. We are also already shipping this fix in an out-of-band webcompat addon update on desktop for several days, and (to my knowledge) have not received any reports yet of worse breakage.
• String changes made/needed: none
• Is Android affected?: yes

firefox-esr140 Uplift Approval Request

• User impact if declined: Rogers customers will see a broken iframe with "Firefox Can’t Open This Page" when trying to view their bills, rather than the billing info.
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: 1) Log in at https://www.rogers.com/

2. Visit https://www.rogers.com/consumer/self-serve/view-bill
3. Confirm that the billing info appears, rather than a broken iframe with "Firefox Can’t Open This Page".

• Risk associated with taking this patch: low
• Explanation of risk level: This only impacts the webcompat site interventions addon, and the rogers.com website. We are also already shipping this fix in an out-of-band webcompat addon update on desktop for several days, and (to my knowledge) have not received any reports yet of worse breakage.
• String changes made/needed: none
• Is Android affected?: yes

Hi twisniewski! I've tried to reproduce the issue, but it seems that we cannot create an account on https://www.rogers.com/ without their customer support being reached out. Also, we cannot see any difference between a fixed and an affected build when using the reduced test case from comment 18.

Do you have a test account that can be shared or know a different method to verify this issue?

I have Rogers Bank account, which was experiencing the same issue ever since a re-design about 6 weeks ago. It uses a different domain (rogersbank.com), and the URL is:
https://selfserve.rogersbank.com/statements

I also have an old Rogers account as discussed above & can still access the billing page.

Both appear to be functioning normally with the fix in 145.0.1.

Please let me know if there's any testing I can assist with (not a web developer, but can follow instructions).

I'm not seeing the same thing on https://selfserve.rogersbank.com/statements. I see something that looks like the attached screenshot. It looks like it's just using a pdf viewer.

Fido (a sub-brand of Rogers) has the same issue with their billing page:
https://www.fido.ca/self-serve/view-bill

The issue is still present in Firefox 145.0.1.

I do (In reply to Andrii Verpakhovskyi [:t_G_M_] from comment #36)

Fido (a sub-brand of Rogers) has the same issue with their billing page:
https://www.fido.ca/self-serve/view-bill

Yes, I do see https://www.fido.ca/bbapp/bbapi.js exists with the same problematic code, so we should be able to extend our intervention to cover Fido easily enough. I'll make a patch.

(In reply to Ciprian Georgiu, Desktop QA from comment #32)

Hi twisniewski! I've tried to reproduce the issue, but it seems that we cannot create an account on https://www.rogers.com/ without their customer support being reached out. Also, we cannot see any difference between a fixed and an affected build when using the reduced test case from comment 18.

Do you have a test account that can be shared or know a different method to verify this issue?

I don't have a test account to share, but I do have a real personal account. I've just verified myself that the issue still exists and that our interventions fixes it, both on the a test nightly build and on Firefox release 145.0.1.. is that fine, or will we need further QA?

I also have a Fido account, if I can be helpful in any way. Thanks.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #35)

Created attachment 9528142 [details]
Statement on rogersbank.com

I'm not seeing the same thing on https://selfserve.rogersbank.com/statements. I see something that looks like the attached screenshot. It looks like it's just using a pdf viewer.

Perhaps they've changed it on their end? I had to use Safari to download my statement last month after their redesign.

I've made a patch which adds the Fido script to our Rogers intervention. Hopefully we'll also get word back soon from the bbapi folks on whether there are more known sites to add.

For those not in Canada, Rogers owns Rogers Communications owns Rogers Bank & Fido (and use the same infrastructure). They also own Chatr & Shaw, and have partial ownership of Glentel. Those are other possibilities.

https://hg.mozilla.org/mozilla-central/rev/3137daa33517