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)
I can reproduce on Nightly50.0a1 windows10. Regression window: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7b94359fb653&tochange=e24844e280a0 Suspect: Bug 734015
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.
Mike, what do you think?
> 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)
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.
(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
[Tracking Requested - why for this release]: Serious flaws related to product reliability
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.
This is extremely likely a duplicate of bug 1293252.
tracking 51+ for now - if this turns out to be a dupe as noted in Comment 14, we can track that bug instead.
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?
(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.
[Tracking Requested - why for this release]:Serious flaws related to product reliability
It's been there for a while and there is no much progress. Mark 51 fix-optional.
I can reproduce in nightly (now 53) on Windows 10.
I think we should not use Firefox. Serious flaws related to product reliability!!
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.
Too late for a fix for 53, as we are in the last week of the 53 beta cycle.
Too late for firefox 52, mass-wontfix.
Still reproducible. William, do you have any further ideas on if this could be a parser issue?
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.