If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

On Google Play Store pages, some elements are not loaded properly when a link is opened as a background tab

NEW
Unassigned

Status

()

Core
DOM
P2
normal
a year ago
a month ago

People

(Reporter: Fanolian, Unassigned)

Tracking

({regression, reproducible})

Trunk
regression, reproducible
Points:
---

Firefox Tracking Flags

(firefox48 wontfix, firefox49 wontfix, firefox-esr45 wontfix, firefox50 fix-optional, firefox51+ wontfix, firefox52- wontfix, firefox-esr52 wontfix, firefox53 wontfix, firefox55 wontfix, firefox56 fix-optional, firefox57 fix-optional)

Details

Attachments

(1 attachment)

(Reporter)

Description

a year ago
Created attachment 8765101 [details]
Google Play Store element missing

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20160624030212

Steps to reproduce:

(This is an old bug that is unrelated to bug 1275917 or bug 1281366)

1. In a new profile, open this link as a background tab: https://play.google.com/store/apps/details?id=org.mozilla.firefox (Tab A)
(If you are hit by bug 1275917, closing the Play Store page and reopen it as background tab should temporary fix it.)
2. Switch to Tab A to see the artifacts.

Optional STR:
3. Focus on Tab A so it is a foreground tab.
4. Reload Tab A. (bug should go away)
5. Switch to other tabs.
6. Reload Tab A as a background tab. (Right click on tab bar and choose Reload Tab)
7. Switch back to Tab A to see artifacts.


Actual results:

Most of the time, some elements are not loaded properly, e.g.
1. Carousel's buttons are missing. (see attachment)
2. Drop down menu of "Categories" does not work.

As a workaround, I have to reload the page as a foreground tab.
_____________


This is an very old bug. I can reproduce it, but not as reliably, in a build as far back as in Dec 2012.

These may or may not be culprits of this bug, but it seems that I can slightly improve the situation by doing one of the followings:
1. Disable e10s. (Hit rate: about 1 in 10)
2. Open Developer Tools on Tab A, and enable "Disable HTTP Cache" in Toolbox Options. (Hit rate: about 1 in 5)

Comment 1

a year ago
I can reproduce on Nightly50.0a1 windows10.

Regression window:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7b94359fb653&tochange=e24844e280a0

Suspect: Bug 734015
Blocks: 734015
Status: UNCONFIRMED → NEW
Component: General → DOM
Ever confirmed: true
Flags: needinfo?(hsivonen)
Flags: needinfo?(bugs)
Keywords: regression, reproducible
I'm not confident we can back out the changes from bug 734015 at this point. Henri will know best, though.

I would love to know if this is happening on other pages or if it's something that the Play store is doing specifically.
This hints about a bug in the Google Store, like it expecting certain elements to be created during a same task or something.
Flags: needinfo?(bugs)
Mike, what do you think?
Flags: needinfo?(miket)
This could get messy...

There's an extra <button aria-label="See More" class="expand-button expand-next" style="">...</button> and a display:none'd <button aria-label="Previous" class="expand-button expand-next" style=""> in the normal load case.

In https://www.gstatic.com/_/play/_/js/k=play.js.en.yKincMd5Gas.O/m=sy39,sy40,pHZCib,sy167,sy260,BZ8Kod,sy174,YEmfo,sy38,sy48,Oqzoie,sy204,ruD2Lc,sy47,h4DLj,sy304,r0kRme,sy122,G7YeLc,sy283,GzQPnc,sy265,xDYNYe,sy149,sy150,sy258,ccz20d,sy268,l62yEe,sy280,MQMzVb,sy308,sy309,bJGPjf,sy175,sy262,NkB5Yd,sy207,epH9Oe,sy49,sy215,nwYYQd,sy58,sy86,sy183,UHw3ec,sy152,O6y8ed,sy104,kPgATb,sy68,sy66,sy56,sy278,h6xJjd,sy277,qPJgQd,sy216,C9GUfc,sy109,sy110,sy141,sy163,ke74Bd,sy36,sy305,sy306,kaKwge,sy189,sy233,sy266,jB6VDf,sy179,sy180,sy257,uuC4Hd,BngI6,sy172,sy279,P2ljte,sy92,sy75,VQcyTe,sy203,lW11I,sy59,DSu7Id,sy55,XyGpve,sy64,sy220,bsXnnd,sy191,r8KIR,sy270,pqKu7c,sy79,PsOe6e,sy190,ZzwEmb,sy148,sy157,sy159,sy151,sy158,sy165,sy168,sy173,sy164,sy52,HozgP,sy217,AO5Sn,sy60,KIL8ye,sy206,ikRapd,sy74,vhibMc,sy196,sy198,sy199,sy200,bPmHCb,sy82,sy195,sy230,QA6GN,sy185,cFXAie,sy76,sy116,sy97,sy176,sy98,sy156,sy83,n0yTLc,uT9F9,sy69,sy96,sy99,nW6Ps,sy205,KrKwmf,sy67,sy117,sy85,sy119,sy118,sy91,sy120,sy121,eDmQYe,sy95,sy208,l88Qmf,sy187,sy188,TfvoCd,sy192,kPfN9d,sy186,ytepuf,sy65,a9ZUbe,pEmmYc,sy214,sy89,sy94,k0XEFb,sy261,kZcz5,sy202,JrpMz,sy281,n3HuA,bt3Kk,sy147,sy197,Mdud6e,sy193,vDC9tb,sy249,sy250,sy256,VAMOzb,sy212,Nqs1f,sy51,sy273,sy303,sy77,Q6g0mb,sy269,DxDj0c,sy177,XO8nne,VSbaQb,sy57,MTZ8td,BfEnZc,sy93,JYKBLd,jO3TP,sy210,PNVjMb,sy184,YK1sC,sy252,sy251,XmMFlb/rt=j/rs=AGlW0sby_uTQztheJDWs0kHVwha87S9Bwg:

az.prototype.w = function(a, b) {
  if (!this.Xe) {
    var c = jQuery(b);
    null == c.attr(bz.gw) && null == c.attr(bz.lw) || c.data("currentFetchPage", 0);
    null != c.attr(bz.hw) && c.data("continuationToken", c.attr(bz.hw));
    var d = c.find(cz.Fh);
    Mja(0 === d.length ? b : d[0]);
    dz(this, c);
    Nja(this, b);
    Oja(this, b)
  }
}

(this.Xe is defined as jQuery("body").hasClass("phone-optimized"), which is false for the Desktop case)

Inside of az.prototype.w, Nja() will create the next and prev buttons via iz(), and puts them in the DOM (as display:none), iff c.find(cz.Eh).length > 0 -- cz.Eh is a div with the class ".expand-page". Then gz() is called, which calls Rja(), which determines if a next/prev button should be shown, once it's in the DOM.

Oja() will add a "clickable" class to each of the screenshots (and set up click handlers) -- but that's not happening in the background tab case, so az.w() isn't getting called at all it seems.

Where it might get called, I haven't found yet -- and I just refreshed the page and Google has a new version with fresh new minified identifiers. \o/

Gonna leave ni? to take a closer look next week.
> Gonna leave ni? to take a closer look next week.

*cough* 

(I've asked etsai to take a look at this in his spare cycles, not considering this a huge priority given the unique STR)
Flags: needinfo?(miket)

Comment 7

a year ago
Same problem with getpen.ru, but this time everything is much worse because almost the whole pages with product description are entirely missing. STR:

Go to http://getpen.ru/
If you see a blank page at the center of the screen, reload the page in order to make Nightly render it correctly. That's the bug.

If you don't see a blank page, open ~5 tabs in the background by clicking on the images of pens, wait until they load

Result:
Contents of those 5 tabs is rendered incorrectly with blank page at the center of the screen instead of the image, comments and description. After reload the pages are displayed correctly. Bug is not reproduced in the latest Opera. Also, as far as I remember, bug is reproduced in FF Stable as well. I'll check that later.
> Go to http://getpen.ru/

Yeah, this reproduces for me when opened as a background tab (right click -> Open in New Tab). And not when opened normally.
Unclear if this is actually the same bug -- would you mind opening a new bug ajfhajf and commenting here with the bug number? That will make things a bit less confusing.

Note: div.span-20:nth-child(9) in the missing version has a computed margin of -11000px, which seems... not normal.
Flags: needinfo?(ajfhajf)

Comment 10

a year ago
(In reply to Mike Taylor [:miketaylr] from comment #9)
> Unclear if this is actually the same bug -- would you mind opening a new bug
> ajfhajf and commenting here with the bug number? That will make things a bit
> less confusing.
Sure! I created a new bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1293252
Thank you!
See Also: → bug 1293252

Comment 12

a year ago
[Tracking Requested - why for this release]: Serious flaws related to product reliability
status-firefox48: --- → wontfix
status-firefox49: --- → affected
status-firefox50: --- → affected
status-firefox51: --- → affected
status-firefox-esr45: --- → wontfix
tracking-firefox51: --- → ?
I can see the issue in the Play Store and we should fix it, but I can also still scroll in the play store carousel and download the product, so I don't think this needs to block 49 release.  We could still take a verified fix in beta.
status-firefox49: affected → fix-optional
status-firefox50: affected → fix-optional
This is extremely likely a duplicate of bug 1293252.
Flags: needinfo?(hsivonen)
tracking 51+ for now - if this turns out to be a dupe as noted in Comment 14, we can track that bug instead.
tracking-firefox51: ? → +
(Reporter)

Comment 16

a year ago
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20160901030202

I can still reproduce this after bug 1293252 is fixed.
Hi :hsivonen,
Per comment #16, this issue can still be reproduced. Can you help shed some light here?
Flags: needinfo?(hsivonen)
(In reply to Gerry Chang [:gchang] from comment #17)
> Per comment #16, this issue can still be reproduced. Can you help shed some
> light here?

I have a hard time guessing what the problem might be. Clearly, this isn't a duplicate of bug 1293252, because its patch didn't fix this one and when this bug manifests itself, the document is set to the no-quirks/standards mode for CSS purposes.

However, the general observation that can be made from bug 1293252 is that when a tab is in the background, the speculative queue gets consumed faster relative to the non-speculative queue than when the tab is in the foreground. This means that when a tab is in the background, more subresources will have been fully loaded from the network via the speculative loading machinery.

It's possible that when a subresource has been fully loaded via the speculative load machinery, the subsequent non-speculative load is faked incorrectly for some resource type. For instance, maybe the subsequent non-speculative load happens too atomically with events related to the load starting and the events related to the load ending firing without the event loop spinning in between.

It might be worthwhile to audit how well the non-speculative load is faked for images, scripts and stylesheets when the whole resource has already been loaded speculatively by the time the non-speculative load is made.
Flags: needinfo?(hsivonen)

Comment 19

a year ago
[Tracking Requested - why for this release]:Serious flaws related to product reliability
status-firefox52: --- → affected
tracking-firefox52: --- → ?

Updated

a year ago
See Also: → bug 1308306

Comment 20

11 months ago
It's been there for a while and there is no much progress. Mark 51 fix-optional.
status-firefox51: affected → fix-optional
I can reproduce in nightly (now 53) on Windows 10.

Comment 22

10 months ago
I think we should not use Firefox.
Serious flaws related to product reliability!!
status-firefox49: fix-optional → wontfix
status-firefox53: --- → affected
I don't think this warrants tracking for 52, it's been around for some time, though if a suitable fix appears we can still consider uplifting.
tracking-firefox52: ? → -
Too late for a fix for 53, as we are in the last week of the 53 beta cycle.
status-firefox53: affected → wontfix
Too late for firefox 52, mass-wontfix.
status-firefox52: affected → wontfix

Updated

4 months ago
Flags: needinfo?(ajfhajf)
Still reproducible. William, do you have any further ideas on if this could be a parser issue?
Flags: needinfo?(wchen)
Priority: -- → P2
No, I don't have any ideas other than what has already been mentioned. Looking at the C++ and JS stack when the button is added to the page doesn't immediately suggest anything parser related. I wasn't able to get very far into the minified/obfuscated JS code to see what was going on.
Flags: needinfo?(wchen)
status-firefox51: fix-optional → wontfix

Updated

2 months ago
status-firefox55: --- → wontfix
status-firefox56: --- → affected
status-firefox57: --- → affected
status-firefox-esr52: --- → wontfix

Updated

a month ago
status-firefox56: affected → fix-optional
status-firefox57: affected → fix-optional
You need to log in before you can comment on or make changes to this bug.