Closed Bug 1291704 Opened 8 years ago Closed 5 years ago

Homepage isn't read from PartnerBrowserCustomizationsProvider at every startup

Categories

(Firefox for Android Graveyard :: Android partner distribution, defect)

Product:
Firefox for Android Graveyard
Component:
Android partner distribution
Version:
48 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: mkaply, Assigned: mkaply)

References

(
URL
)

Details

As reported by partner. Not sure if this is the expected behavior or not.

We found that Firefox query homepage from "content://com.android.partnerbrowsercustomizations/homepage" url ,only in the first time firefox start.

[Test step]
1: start firefox and chrome browser, their homepage is "http://example.org"
2: change homepage in DM Server
3: no need kill firefox or chrome process, just relaunch both browser. Observe the homepage of two browser.

[Test result]
chrome's homepage change to new one.
firefox's homepage not change.
The "homepage implementation" will only open the homepage on app start if there's no session to restore. If there's still a session (e.g. with only the old homepage open) then this session is restored (default pref).
(In reply to Sebastian Kaspari (:sebastian) from comment #1)
> The "homepage implementation" will only open the homepage on app start if
> there's no session to restore. If there's still a session (e.g. with only
> the old homepage open) then this session is restored (default pref).

That's what I thought. I think the primary difference between Chrome and Firefox here is that on Chrome when you close the last tab, the browser goes away completely and so when you restart it, you always have a new session, so it's more obvious that it goes to the homepage on start.

On Firefox, we maintain the session, so when you restart Firefox from the icon, it goes back to top sites with no way to go to the homepage. Unless the browser is actually completely closed.

Is there any way to change the Firefox behavior so that closing the last tab goes to the website homepage instead of top sites?
(In reply to Mike Kaply [:mkaply] from comment #2)
> Is there any way to change the Firefox behavior so that closing the last tab
> goes to the website homepage instead of top sites?

That's actually what I fixed in bug 1261008: After closing all tabs (=> Just having one [or more] tabs with just about:home and no history) we do not restore the about:home tab(s) but instead load the homepage. So *this* should work. However the steps in comment 0 do not mention closing tabs.
(In reply to Mike Kaply [:mkaply] from comment #2)
> I think the primary difference between Chrome and
> Firefox here is that on Chrome when you close the last tab, the browser goes
> away completely and so when you restart it, you always have a new session,
> so it's more obvious that it goes to the homepage on start.

Mh, yeah, it seems like Chrome only does this when a homepage is set. Probably to avoid exactly this scenario.


(In reply to Mike Kaply [:mkaply] from comment #2)
> Is there any way to change the Firefox behavior so that closing the last tab
> goes to the website homepage instead of top sites?

Theoretically yes. The code for that is here:
https://dxr.mozilla.org/mozilla-central/source/mobile/android/base/java/org/mozilla/gecko/Tabs.java#372

There's some refactoring needed to actually be able to get the homepage here (or notify some component that knows about the homepage). I'll also flag antlam here because this would change the navigation inside the app.
Flags: needinfo?(alam)
So here's what I learned through all of this.

1. The main thing that changed this behavior is bug 1219343. This bug changed Fennec to default to always session restore. This means that 99% of the time, the homepage is not read and shown at startup. Before Firefox 48, it was.

2. For some reason, the pref for doing session restore (quit vs. always) is a app level preference, so I can't change it back via the distribution file.

3. The only way to get Firefox to reread the preference from the provider is to close all tabs until your only only tab is the Firefox about:home. Then close Firefox and on next start, it will show the new homepage (because there is no session to restore)

So we do read the new homepage from the provider, it's just difficult to get in a situation where it does that.

I have a couple thoughts.

1. We should decide if we really meant for session restore to be an app level preference. (I'm not even sure what the difference is between app level and profile level android prefs). If there are app level prefs that a distribution might need to set, we need to add support for this to the distribution code.

2. We really need to rethink homepage on Fennec, maybe copying more of the stuff that Chrome has done. Some of the behaviors are just strange. Closing the last tab and then getting a new tab opened is awkward especially when you have a homepage set and that page doesn't open to that homepage.

I'm going to document how this works for the partner and hopefully we'll be good enough.
So I've investigated this more and it appears the reason the session restore preference is an app level preference is because of how early it is read.

I tried to make some modifications to set it via the distribution, but it is read before the distribution preferences are read.

I also investigated deciding whether or not to do session restore based on the presence of a homepage, but again, the session restore decision is done before distribution preferences are read...
We should loop in Barbara here too. I know we heavily debated the pros vs cons of different behaviours to Set a Homepage before.

(In reply to Mike Kaply [:mkaply] from comment #2)
> Is there any way to change the Firefox behavior so that closing the last tab
> goes to the website homepage instead of top sites?

Is this what this bug is about? 

This was one of the behaviours we thought about but ultimately decided against it for a variety of reasons. But I still have UX for this.

Barbara, is this something we should do?
Flags: needinfo?(alam) → needinfo?(bbermes)
> Is this what this bug is about? 

Part of it yes. But at the core, we didn't realize it but the quit/restore change happened in Firefox 48 as well, so all along the partner was testing seeing one behavior, but we shipped a different behavior.

I filed another bug to try to get a handle on how we should be handling the homepage.

https://bugzilla.mozilla.org/show_bug.cgi?id=1293713

I really wish we could mess with session restore via distribution but unfortunately it's an app preference that gets read before the distribution does...
See Also: → 1286564
(In reply to Mike Kaply [:mkaply] from comment #8)
> I really wish we could mess with session restore via distribution but
> unfortunately it's an app preference that gets read before the distribution
> does...

That's maybe a bug to file to. Adding support for app preferences should be simple and it will avoid that we run into such a situation again - even though if it's to late for this specific problem.
Can you, Mike or Sebastian, file a bug for comment 9 --> I consider this a pretty important thing to do for partner distributions. We said we'd focus on making the process and distribution settings easier.

Anthony, what were the biggest concerns of not doing what Mike suggested in comments 7 (requoted by you, antlam)? 

So comment 3 says that the code is actually in it to behave the way Mike suggested but it's not working?
Flags: needinfo?(bbermes)
> Can you, Mike or Sebastian, file a bug for comment 9 --> I consider this a pretty important thing to do for partner distributions. We said we'd focus on making the process and distribution settings easier.

I'll take care of that.

> So comment 3 says that the code is actually in it to behave the way Mike suggested but it's not working?

I'll check on nightly.
Filed bug 1295675
> So comment 3 says that the code is actually in it to behave the way Mike suggested but it's not working?

Actually, it is working, it's just hard to hit this scenario. You have to close every tab down to just a "home" tab and then close the browser. In that case there is no session.

So what sebastian did is working.
(In reply to Barbara Bermes [:barbara] from comment #10)
> Anthony, what were the biggest concerns of not doing what Mike suggested in
> comments 7 (requoted by you, antlam)? 

So, all other things being the same. Are you suggesting that the UX after a home page is set will now be:

IF user closes the LAST tab --> open a new tab --> load the set homepage URL 

IF user closes any other tab --> nothing happens

IF user opens a NEW tab --> open a new tab --> show Top Sites/ default panel (same as before)

In my head, this might work. But I think we should wrangle all the Home page bugs together to triage and make sure we didn't miss anything.

Is there an Aha! card or a meta?
Flags: needinfo?(bbermes)
Blocks: 1314038
So rereading this, this is reporting a different problem than we thought.

The report here is that the homepage should be read from the chrome server any time it is requested.

It should not be set at startup once and never queried again.
Hi Mike 
I think we can close this bug?
Flags: needinfo?(mozilla)
con't to comment 17. We can close this because bug 1293713 has landed?
No, this is a separate issue. They are asking that we read the chrome bookmarks provider any time we request the homepage (versus only reading it at startup and never setting it again)
Flags: needinfo?(mozilla)

We're not going to address this in Fennec.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.