Closed
Bug 1363052
Opened 8 years ago
Closed 7 years ago
Web Apps - Re-launching a web app with an internal/external page opened, resets is to the homepage
Categories
(Firefox for Android Graveyard :: Web Apps (PWAs), defect, P1)
Tracking
(firefox55 unaffected, firefox57 affected, firefox58 affected)
RESOLVED
WORKSFORME
Tracking | Status | |
---|---|---|
firefox55 | --- | unaffected |
firefox57 | --- | affected |
firefox58 | --- | affected |
People
(Reporter: ohorvath, Unassigned)
References
Details
(Whiteboard: [pwa-front-end])
Device: Nexus 6 (Android 7);
Build: Nightly 55.0a1 (2017-05-08);
Steps to reproduce:
1. Open a web app and navigate to an external link, that is opened inside the web app (eg. react-hn.appspot.com).
2. Tap the device's home button.
3. With the web app minimized, tap on its home screen icon to launch it again.
Expected result:
The web app shows the external page from where it was minimized.
Actual result:
The web app is reset to the homepage.
Notes: not reproducing on Chrome web apps.
Reporter | ||
Updated•8 years ago
|
Blocks: 1285858
status-firefox55:
--- → affected
Comment 1•8 years ago
|
||
So this is done to handle the case in which an activity is being reused for another app http://searchfox.org/mozilla-central/source/mobile/android/base/java/org/mozilla/gecko/webapps/WebAppActivity.java#176, We may be able to do a better job of detecting when an activity is being reused
Comment 2•8 years ago
|
||
I'm not sure if this would be entirely fool-proof, but when initially opening a tab for a web app activity, we store the local manifest path as received from the intent on the tab (https://dxr.mozilla.org/mozilla-central/rev/b21b974d60d3075ae24f6fb1bae75d0f122f28fc/mobile/android/base/java/org/mozilla/gecko/Tabs.java#1176). Maybe we can use that to compare it with the new intent? I think the caller of onTabSelectFromIntent (and for symmetry onTabOpenFromIntent as well) could be modified to pass on the respective intent as well, so the WebAppActivity could then use it for comparison.
Updated•8 years ago
|
Priority: -- → P1
Updated•8 years ago
|
Assignee: nobody → dale
Comment 3•8 years ago
|
||
Resetting and will pick this up again when GeckoView PWA's relands
Assignee: dale → nobody
Reporter | ||
Comment 4•7 years ago
|
||
Still reproducing on Nightly 57.0a1, using GeckoView.
Blocks: progressive-apps
status-firefox57:
--- → affected
Summary: Web Apps - Re-launching a web app with an external page opened, resets is to the homepage → Web Apps - Re-launching a web app with an internal/external page opened, resets is to the homepage
Updated•7 years ago
|
Flags: needinfo?(cnevinchen)
Updated•7 years ago
|
Flags: needinfo?(cnevinchen)
Whiteboard: [pwa-front-end]
Comment 5•7 years ago
|
||
Needs to be considered in the context of https://bugzilla.mozilla.org/show_bug.cgi?id=1389236
Comment 6•7 years ago
|
||
Hi Oana, Can you verify again with the latest GeckoView PWA implementation?
I can't seem to reproduce the original bug
Thanks
Joe
Flags: needinfo?(oana.horvath)
Reporter | ||
Comment 7•7 years ago
|
||
There is a difference between how the PWA's external links are handled:
1. react-hn.appspot.com opens external links as internal pages, not in custom tabs. For this PWA, the pages are restored (but they should open in custom tabs and that's a different issue).
2. Twitter pwa opens external links in custom tabs, but these are not restored. For example, on Twitter: open an external link in a custom tab, minimize the web app and tap the launcher again. It won't restore the custom tab opened.
So, the issue is still reproducible having external links opened in custom tabs.
Flags: needinfo?(oana.horvath)
We use custom tabs for external links now, so this no longer occurs.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 9•7 years ago
|
||
The issue still occurs with using custom tabs for external links, as I've mentioned in comment 7 (with the mention that point #1 from that comment is invalid now). Let me know if I'm misunderstanding the expected behavior, or if I should reopen this bug.
status-firefox58:
--- → affected
Flags: needinfo?(snorp)
Reporter | ||
Comment 10•7 years ago
|
||
Actually, I've just seen that Chrome does the same thing.
Ah, I understand comment #7 better now. I think our current behavior is correct.
Flags: needinfo?(snorp)
Updated•4 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•