Open Bug 1481132 Opened 6 years ago Updated 2 years ago

[Android] businessinsider.com flashes 3 times when you reload or navigate away

Categories

(Core :: Web Painting, defect, P3)

63 Branch
Unspecified
Android
defect

Tracking

()

Performance Impact none
Tracking Status
firefox63 --- affected

People

(Reporter: karlcow, Unassigned)

References

()

Details

(Whiteboard: [webcompat])

Attachments

(2 files, 1 obsolete file)

This is a spin off of https://webcompat.com/issues/6148

Steps to reproduce
1. with Firefox on Android.
2. Go to Business Insider  http://www.businessinsider.com/
3. Wait for the full load.
4. tap an article

Expected:
Article displays

Actual:
Article flashes 3 times.


Performance profile
https://perfht.ml/2Ks8aAp
Though I can't reproduce it (since I am accessing from Japen?), it seems to me that the flicker seems to be opacity transitions as per the video [1] in the webcompat issue.

https://webcompat.com/issues/6148#issuecomment-353094790
Priority: -- → P3
from Japan, you can tap on the 3 bar menu, 
go down the menu select US edition :)
Flags: needinfo?(hikezoe)
In case it's helpful, here's a shorter profile, of me simply reloading the businessinsider.com front page (which triggers the same triple-fade "flash" before the page reloads, on my Pixel 2 android device with Firefox nightly):
  https://perfht.ml/2vGN5sF
...and another profile of a reload that triggers the triple flash:  https://perfht.ml/2vJVbRh

(Sadly, it looks like C++ symbols do not get symbolicated correctly.)
This also happens if I simply type another site's URL into the urlbar (e.g. https://www.mozilla.org or https://www.yahoo.com) and hit 'enter' on my android keyboard, to navigate somewhere else entirely.
Summary: Content flashes 3 times before being displayed → [Android] businessinsider.com flashes 3 times when you reload or navigate away
I think each fadeout is from them calling...
> removeClass("visible");
> addClass("hidden");

...on the page's body element, it seems. The "hidden" class causes these styles to be applied to that element:
====
.hidden {
    opacity: 0;
    transition: opacity .3s ease-out;
}
====
 
...and that clearly triggers an opacity animation.  Note: I can work around the issue if I add this style to one of their stylesheets (using WebIDE to get devtools for my mobile browser)
> body { opacity: 1 !important }

From grepping through their scripts, it looks like they have a function called "A" which does trigger this class swap:

  function A(D) {
    [...]
    var G = d('body');
    D = D || window.event;
    if (D.type in C) {
      if (C[D.type] === 'hidden') {
        G.removeClass('visible');
        G.addClass('hidden')
      } else {
        G.removeClass('hidden');
        G.addClass('visible')
      }
     [...]

The code directly above this sets up "A" as the handler for onpageshow, onpagehide, onfocus, onblur, and visibilitychange.  I suspect that we're firing several of these events back to back, perhaps... Or, alternately, maybe there's some race condition between the next page's "ready to paint some content" notifications vs. this page's "paint an opacity-->0 animation" behavior that triggers the weird fadeout behavior?
Here's a reduced testcase.  If I click one of the links in this testcase, I see the opacity fade-out animation play multiple times.

What's interesting is:
 - This animation comes from adding the .hidden class to the <body>.
 - That class comes with several other style changes as well.
 - However, none of those other style changes show up at all (transitioned or not) on page navigation. Only the opacity animation plays, AND it plays multiple times.
 - Also: I've made pagehide trigger a dom modification -- adding some extra text -- and that shows up in Firefox for Android (just once), whereas it never shows up in Chrome for Android, nor does it ever show up in Firefox for Desktop.

Bottom line, I think we're intending to suppress paints of the old page after we fire pagehide, but clearly we are not -- and something about the loading-next-page process makes us trigger some old paints of the previous page.
(The "manually add/remove" buttons in the testcase are just for experimentation, to see what the pagehide handler's results are without actually having to do any navigation.)
Attached file testcase 1
Attachment #8998030 - Attachment description: testcase 1 → testcase 0.9 (hiding since it doesn't clean up its extra text at the end, and that might be confusing)
Attachment #8998030 - Attachment is obsolete: true
[hand-waving]
My guess here is that we're suppressing paints on the navigated-to page, but we're still getting "ready for a paint" notifications of some sort, which triggers us to paint the old page because the new page has painting suppressed.
Component: Layout → Layout: Web Painting
STR for testcase 1 and 2:
 1. Load testcase.
 2. Click any of the links.

EXPECTED RESULTS FOR BOTH TESTCASES:
The testcase shouldn't change its rendering; we should simply load the navigated-to page.

ACTUAL RESULTS FOR TESTCASE 1:
An opacity transition plays several times while the new page is loading. Also, the "HERE'S SOME EXTRA TEXT" text shows up at the end of the page.

ACTUAL RESULTS FOR TESTCASE 2:
The page background turns red, a border appears, and padding/margin appear as well.  And the "HERE'S SOME EXTRA TEXT" text shows up at the end.

All of the "actual results" changes are made in the "pagehide" event, so they shouldn't show up (because they expect the page to be hidden).

CC'ing some folks who might know about painting on Android... Does this ring bell?
Actually, I can't reproduce this in (GeckoView-based) Focus Nightly, so I think this must be a quirk of how current Firefox for Android does navigation, which will likely go away once we switch it to using GeckoView like Focus Nightly does.

That means this is probably low-priority, since any fixes to Firefox-for-Android stuff here would become obsolete/unnecessary as soon as we switch to GeckoView anyway.

I'm going to call this [qf-], on that reasoning. If anyone can reproduce this in Focus with GeckoView, though (or in a future Firefox with GeckoView), please renominate.
Flags: needinfo?(hikezoe)
Whiteboard: [webcompat] [qf] → [webcompat] [qf-]
(In reply to Daniel Holbert [:dholbert] from comment #13)
> [...] I think this must be a quirk of how current Firefox for Android does
> navigation, which will likely go away once we switch it to using GeckoView
> like Focus Nightly does.

Further validation: I tested the "GeckoView example app"[1], too, and I confirmed that I cannot reproduce this issue there (I tried both of the attached testcases, as well as the businessinsider.com page itself.)

[1] I used the geckoview_example.apk artifact, from this recent mozilla-central run: https://treeherder.mozilla.org/logviewer.html#?job_id=192550851&repo=mozilla-central )

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Webcompat Priority: --- → ?

See bug 1547409. Migrating whiteboard priority tags to program flags.

Performance Impact: --- → -
Whiteboard: [webcompat] [qf-] → [webcompat]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: