Closed Bug 1129168 Opened 5 years ago Closed 5 years ago

Remote Tabs panel flickers after Bug 1063742


(Firefox for Android :: General, defect)

Not set



Firefox 39
Tracking Status
firefox38 --- fixed
firefox39 --- fixed
fennec 38+ ---


(Reporter: nalexander, Assigned: vivek, Mentored)




(1 file, 3 obsolete files)

STR: Scroll to Synced Tabs panel; scroll to adjacent panel; return to Synced Tabs panel; observe flicker as panel is re-painted.

Is this due to the fragment cache not working?  Is this due to forced load() calls?  Is it possible we're seeing multiple loading paints?  Do we have an issue with the Firefox Account Loader?

This is a regression from Bug 1063742.
I would like this to track Fennec 38.
tracking-fennec: --- → ?
margaret: I think this is related to the load issue you described in
tracking-fennec: ? → 38+
Attached patch 1129168.patch (obsolete) — Splinter Review
Patch changes:
1) Fragment Cache extended to include orientation along with action
2) Panel reload avoided for every rotation in tablets

Can you please test this on tablet
Flags: needinfo?(nalexander)
Attachment #8563160 - Flags: review?(nalexander)
Comment on attachment 8563160 [details] [diff] [review]

Review of attachment 8563160 [details] [diff] [review]:

This is all sensible, but it doesn't address the actual problem.  To see the flash (on all of my devices), select Synced Tabs, scroll manually all the way to the end of the panels, then scroll back to Synced Tabs.  You should see the flash.

What is happening is that the underlying RemoteTabsPanel fragment is *different*.  That clears the cache entirely.  I don't know why we see the internal fragments when we scroll back -- I guess they are still in the view hierarchy? -- when the RemoteTabsPanel fragment is replaced.  You can verify this by printing this and the fragment cache, etc, during the show operation.

I checked out the relevant sources from revision 145b1a56988e^ (the revision before landing Bug 1063742) and the flash is present.  It may have to do with reloading the tab data itself.

In any case, this doesn't address the issue on any of my devices.  I'm not sure we care enough to keep pushing on this right now.

::: mobile/android/base/home/
@@ +23,5 @@
>  import android.os.Bundle;
>  import;
>  import;
>  import;
> +import;

Are you kidding me?  How did I not know about this!

@@ +54,5 @@
>      private Fragment mCurrentFragment;
>      // A lazily-populated cache of fragments corresponding to the possible
>      // system account states. We don't want to re-create panels unnecessarily,
> +    // because that can cause flickering. Key is a pair of {@link android.content.res.Configuration}

Can you enumerate the expected values: one of 


@@ +216,5 @@
>              }
>              return mFallbackFragment;
>          }
> +        // Using orientation to generate key pair in tablets.


// When the layout depends on the device orientation, cache the fragments for each orientation keyed by the orientation constant.  Otherwise, cache the fragment keyed by unknown.

And this is one of the rare times when the helper method obscures rather than clarifies.  I'd fold the logic inline here to keep it all in one place.

@@ +224,3 @@
>          // On a tablet devices with accounts authenticated, create a new fragment based on the current orientation.
>          // The cached fragment in the above case may not be the valid fragment for the current orientation.
>          if (fragment == null || (HardwareUtils.isTablet() && actionNeeded == Action.None)) {

Shouldn't you not need the || clause here?  I expect you to handle this special case at the caching layer.
Attachment #8563160 - Flags: review?(nalexander) → feedback+
margaret: you are quite familiar with the panel loading code -- did you ever see the behaviour above?  Did you work around it some way?
Flags: needinfo?(margaret.leibovic)
Flags: needinfo?(nalexander)
Attached patch 1129168.patch (obsolete) — Splinter Review
Remote panel flicker changes.
* Cached fragment based on orientation
* mCurrentFragment updated from fragment manager, this avoids unnecessarily reloading a new fragment, which Fragments are recreated.
Attachment #8563160 - Attachment is obsolete: true
Attachment #8565163 - Flags: review?(nalexander)
Can you please help me test this on tablet
Flags: needinfo?(nalexander)
Vivek, what's the status here? I remember nalexander talking to me last week about how you two figured out what's going wrong here. Is this patch still the most up-to-date version? I can help you test on a tablet if you need that.
Flags: needinfo?(margaret.leibovic) → needinfo?(vivekb.balakrishnan)
Assignee: nobody → vivekb.balakrishnan
Margaret, I intend to submit new patch by EOD. The idea was to get rid of cache in RemoteTabsPanel and use the combination of childFragmentManager and tags based on action and orientation to avoid reloading the fragment if it was already handled by the framework.
Flags: needinfo?(vivekb.balakrishnan)
Attached patch 1129168.patch (obsolete) — Splinter Review
A patch to prevent flickering:
* Fragment are committed to transaction with  a tag. Account action and current orientation are stored as fragment args.
* Upon fragment recreation, these values are retrieved from the fragment in the back-stack to decide whether a new fragment (for current orientation) needs to created.
* Fragment cache was removed. Fragment life-cycle is handled automagically by the android framework.

@Margaret : can you please help me test this on a tablet.
Attachment #8565163 - Attachment is obsolete: true
Attachment #8565163 - Flags: review?(nalexander)
Attachment #8570228 - Flags: review?(nalexander)
Attachment #8570228 - Flags: feedback?(margaret.leibovic)
Comment on attachment 8570228 [details] [diff] [review]

Review of attachment 8570228 [details] [diff] [review]:

::: mobile/android/base/home/
@@ +71,5 @@
> +            final int fragmentOrientation = bundle.getInt(FRAGMENT_ORIENTATION);
> +            if (fragmentAction.equals( && fragmentOrientation != GeckoScreenOrientation.getInstance().getAndroidOrientation()) {
> +                // The Fragment in the back-stack is not for the current configuration.
> +                // As the fragment becomes visible only after onStart callback, We can safely pop it from the back-stack.
> +                getChildFragmentManager().popBackStackImmediate();

I don't understand this.  How do you know the fragment you found using findFragmentByTag is at the top of the stack?

I feel like we might want to beginTransaction, remove, endTransaction to get it out of the back stack robustly.  Maybe?

@@ +85,5 @@
>          getLoaderManager().initLoader(LOADER_ID_ACCOUNT, null, mAccountLoaderCallbacks);
>      }
> +    private void showSubPanel(Account account) {
> +        final Action actionNeeded = getActionNeeded(account);

Can you extract some helper that takes the actionNeeded and does the fishing out of the fragment manager below?  It seems like we do the same logic here and above.
Attachment #8570228 - Flags: review?(nalexander)
Attachment #8570228 - Flags: feedback?(margaret.leibovic)
Attachment #8570228 - Flags: feedback+
Attached patch 1129168.patchSplinter Review
A new patch with review nits corrected.
* fragment removed through transaction
* common code moved to a function.

@Nick: can you please help me and test this in a tablet. thanks.
Attachment #8570228 - Attachment is obsolete: true
Attachment #8573522 - Flags: review?(nalexander)
Comment on attachment 8573522 [details] [diff] [review]

Review of attachment 8573522 [details] [diff] [review]:

This looks good and works well on my tablet!  I'll land with some cosmetic changes (renaming and comments).
Attachment #8573522 - Flags: review?(nalexander) → review+
Flags: needinfo?(nalexander)
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 39
Comment on attachment 8573522 [details] [diff] [review]

Approval Request Comment
[Feature/regressing bug #]: Bug 1137655, among others.
[User impact if declined]: crashes switching from Synced Tabs panel.
[Describe test coverage new/current, TreeHerder]: manual testing by nalexander.
[Risks and why]: we could mutate the crash stack.
[String/UUID change made/needed]: none.
Attachment #8573522 - Flags: approval-mozilla-aurora?
Attachment #8573522 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.