Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consolidated list of Android hardware back button issues #16611

Open
dylanvdmerwe opened this issue Dec 6, 2018 · 32 comments

Comments

@dylanvdmerwe
Copy link
Contributor

commented Dec 6, 2018

Describe the Bug
This is a list of functionality that must work with the Android hardware back button. I want to try and keep a list of them in one place so we can finally verify the hardware back button works correctly as this has been problematic since v2.

The back button here refers to the hardware back button.

Web

  • Back button to navigate back to previous view.
  • (#15422) If a modal is open, back button to close/dismiss the modal.
  • If more than one modal is open at a time, back button should dismiss modals in the order they were opened (stack).
  • If a popup is open, the back button should dismiss any popup.
  • If a popup is open on top of a modal, the popup should be dismissed first on back button press.
  • Pressing back in a tabbed application should navigate the user backward across tabs. (for example: Tab 1 -> Page 1 -> Page 2 -> Tab 2 -> Page 3 -> back -> Page 2 -> back -> Page 1) (similar issue: #18721)
  • When side menu is open, back button should close the side menu before navigating.

Cordova/App

  • (similar: #17689 #17984) When on the root page, pressing the back button should close the app (standard Android behaviour)
  • There should be an event that fires should the user want to show a confirmation popup before the back button closes the app.
  • Back button behaviour should be consistent between web and app (as per web list above)
  • (#16505) If a native view is opened (i.e. Camera), pressing back button should dismiss native view back into the webview. (for example: Page 1 -> Page 2 -> Open camera -> back -> camera closed onto Page 2)
  • When side menu is open, back button should close the side menu before navigating.
  • #17589 back button not working with ion-button and href to page
  • #17824 subscribeWithPriority not working properly w/ popups & higher priority levels

Expected Behavior
Ultimately the user should not need to have to intervene with events, subscriptions or HostListener to handle back button navigation.

@ionitron-bot ionitron-bot bot added the triage label Dec 6, 2018

@dylanvdmerwe dylanvdmerwe changed the title [4.0.0-beta.17] Android hardware back button issues [4.0.0-beta.17] Consolidated list of Android hardware back button issues Dec 6, 2018

@manucorporat manucorporat added this to Backlog 🤖 in Ionic Core via automation Dec 6, 2018

@ionitron-bot ionitron-bot bot removed the triage label Dec 6, 2018

@olivermuc

This comment has been minimized.

Copy link

commented Dec 21, 2018

It would be nice to see some progress here as well, especially around camera use, as the camera is certainly one an often used device feature.

Currently, cancelling out of camera use is still "broken" per #16505

@Newbie012

This comment has been minimized.

Copy link

commented Dec 27, 2018

If the menu is open, then it should close it instead of going back to the previous view.

@amitairos

This comment has been minimized.

Copy link

commented Jan 8, 2019

Any update on these issues?

@amitairos

This comment has been minimized.

Copy link

commented Jan 16, 2019

Is there any update on any of these issues? Are they in progress? We're already in rc2...

@dylanvdmerwe dylanvdmerwe changed the title [4.0.0-beta.17] Consolidated list of Android hardware back button issues Consolidated list of Android hardware back button issues Jan 16, 2019

@KevinKelchen

This comment has been minimized.

Copy link

commented Jan 24, 2019

Back button behaviour should be consistent between web and app (as per web list above)

I was expecting the ion-back-button to also be consistent with web and app. I think it seems odd for someone using an Ionic app to experience different behaviors depending on whether they're using the hardware or software back button; it would probably confuse users.

FWIW, I posted a comment here outlining issues our team has had with ion-back-button's behavior.

@amitairos

This comment has been minimized.

Copy link

commented Jan 24, 2019

Is this issue being addressed? We're already in production, and there are still problems with this, in particularly with the web app/pwa

@brandyscarney brandyscarney moved this from Backlog 🤖 to On deck ⚾️ in Ionic Core Jan 25, 2019

@alaa-alshamy

This comment has been minimized.

Copy link

commented Jan 30, 2019

this is so important issue, simply any overlay(alert/popover/modal/actionsheet/etc) should close when any back button clicked (browser back/android back button)

i think it's simple in the apps but in the web/pwa will be more difficult because we should work with the history state of the browser so push a new state when an overlay open and make back to remove the state when the overlay is close

i already made a complicated code to achieve this behavior in ionic 3

i hope u can fix this soon

@KevinKelchen

This comment has been minimized.

Copy link

commented Jan 30, 2019

I agree with the UX of the browser/Android back button dismissing a modal. If a modal was full-screen, for example, the user would probably expect it to work like a routed Component in that it "goes back to what was showing before"/dismisses.

At the same time, I think we'd want to be careful about an overlay's relationship to the browser history.

For example, if the history state was modified, how would that affect the Angular router with a CanDeactivate guard on the Page you launched the modal from? Perhaps you wouldn't want that to trigger (haven't tested if it would).

Also, I would not expect that overlays remain in the browser history stack. Imagine using browser back/forward and navigating to an entry in the history stack for an overlay. I would not expect the overlay to somehow re-launch, with its preserved state no less, nor would I expect the back/forward action to appear to do nothing which would probably make it feel broken and confusing to users. Not modifying the browser history is actually one of the reasons our team has just migrated several Page Components to modals.

There's a lot involved here and just saying we'll want to carefully think about the various contexts and use cases to guide the behavior changes that are planned. 🙂

@alaa-alshamy

This comment has been minimized.

Copy link

commented Jan 31, 2019

mmm so there's various needs.

so i think to make all the need cases, must add some behavior as option.

and i think using a hash fragment in overlays will prevent the expect of re-launch or feel broken, because no one will expect a hash to do some thing like launch some thing or do some thing important

so making an option to add this behavior to the overlays will achieve all the need in my opinion :)

also i think some people will like if they can make a modal with a path (with route), so if the modal open from a context inside the app will open as modal as normal and change the url to it's route, and if it open from the url it should open as a page. so simply we can open component as modal or as page.

@brandyscarney brandyscarney pinned this issue Feb 8, 2019

@alaa-alshamy

This comment has been minimized.

Copy link

commented Feb 14, 2019

i think the easiest way to do so is using multiple router outlets.

so we can use a "popup" outlet as described here: https://angular.io/guide/router#displaying-multiple-routes-in-named-outlets

@rony53

This comment has been minimized.

Copy link

commented Mar 6, 2019

Thanks , Hope in next update we will got this issue solved , but please do it 1st , i have to publish my apps :)

@rony53

This comment has been minimized.

Copy link

commented Mar 6, 2019

Also add rootNev button like ionic 3 , when we use any kind of nav function , the hide the menu bar

@moritzgloeckl

This comment has been minimized.

Copy link

commented Mar 13, 2019

We've also noticed that the hardware back button on Android behaves differently than the browser back button, especially when using replaceUrl: true and skipLocationChange: true in Angular routing.

@RHinderiks

This comment has been minimized.

Copy link

commented Mar 26, 2019

Is there any news on this? Beta release of our app revealed this at the number one issue for android users. So before we can do a version 1 release we would like this to be fixed

@liamdebeasi

This comment has been minimized.

Copy link
Member

commented Apr 4, 2019

Hi everyone,

We are aware of these issues and are going to be looking into them now. We are currently prioritizing these issues and hope to have more updates to share soon.

We appreciate your patience as we work through these issues.
Thanks!

@rony53

This comment has been minimized.

Copy link

commented Apr 7, 2019

Hi everyone,

We are aware of these issues and are going to be looking into them now. We are currently prioritizing these issues and hope to have more updates to share soon.

We appreciate your patience as we work through these issues.
Thanks!

Thanks liamdebeasi ,
We are waiting for the next update, where we get all issue fixed. But we don't know how long we need to wait :) . But it's ok. thanks for your update.
Best
Rony

@ebeliejinfren

This comment has been minimized.

Copy link

commented Apr 8, 2019

it's important issue and we except to solve this soon but after 4 month and updates that not solve

@Dak1411

This comment has been minimized.

Copy link

commented Apr 8, 2019

@liamdebeasi,
Waiting for the day your team comes with the solution...😊

@untilbit

This comment has been minimized.

Copy link

commented Apr 10, 2019

Still waiting for a solution.

@untilbit

This comment has been minimized.

Copy link

commented Apr 10, 2019

Hi everyone,

We are aware of these issues and are going to be looking into them now. We are currently prioritizing these issues and hope to have more updates to share soon.

We appreciate your patience as we work through these issues.
Thanks!

Any update? This is critical issue to be solved. Withoud this many apps are going to stay in ionic 3.

@ionic-team ionic-team locked as off topic and limited conversation to collaborators Apr 10, 2019

@liamdebeasi

This comment has been minimized.

Copy link
Member

commented Apr 10, 2019

I am locking this thread so we don't get too off topic.

I am still working on these issues and will post here when I have more to share. We aren't forgetting about you, just trying to make sure this all gets taken care of properly 🙂

For any new bugs please open a Bug Report, and I will add them here.

@liamdebeasi liamdebeasi moved this from On deck ⚾️ to Backlog 🤖 in Ionic Core Jun 11, 2019

@ionic-team ionic-team unlocked this conversation Jul 8, 2019

@libattistella

This comment has been minimized.

Copy link

commented Jul 18, 2019

Hi! Any update on these issues? Particulary this one
#17824 subscribeWithPriority not working properly w/ popups & higher priority levels

@tanoabeleyra

This comment has been minimized.

Copy link

commented Jul 18, 2019

This is my workaround for a PWA: tanoabeleyra/ionic-back-button-workaround@77aa0ea

Back button does pop or closes any overlay (alert, modal, picker, etc.).
I just need to fix the back button not closing the app, if anyone knows how to do it I would really appreciate some help.

@Dak1411

This comment has been minimized.

Copy link

commented Jul 18, 2019

@rony53

This comment has been minimized.

Copy link

commented Jul 18, 2019

I think ionic loss his popularity for its internal debag issue .. we got ionic 5.x but still app closing issue not fixed . if the android user can't close the app then why they use this platform? I am really scared .. maybe my clients are looking for a new developer for their project ...

@liamdebeasi

This comment has been minimized.

Copy link
Member

commented Jul 18, 2019

Hi everyone,

Wanted to provide an update here. We are still committed to resolving these issues. Because we cannot cancel/prevent a back button event and because we have multiple navigation stacks interacting via different frameworks, developing solutions to these issues can take time due to the complexity of some of these tasks as well as writing tests to ensure functionality does not break in the future.

Regarding @rony53's comment about us closing the issue due to Ionic 5: I think you are confusing the Ionic CLI for the Ionic Framework, which are two different things. The CLI has released a version 5.0, but the Framework has not: https://ionicframework.com/blog/ionic-cli-v5-brings-react-beta-support/. Additionally, as this issue is still open, we have not closed it nor have we forgotten about this issue.

We’ve been focused on getting Ionic 4.6.0 out that introduced some really great performance improvements due to the Stencil One upgrade. Now that Ionic 4.6 has been released, we are looking to loop back to some of these issues.

We hope to have more updates regarding these issues soon. Additionally, we absolutely welcome community PRs and would love any assistance in getting this issues resolved.

Thanks!

@tanoabeleyra

This comment has been minimized.

Copy link

commented Jul 18, 2019

Hi @liamdebeasi, that's great to hear. I really hope you can fix this because it's critical, we can't deliver an Android app where the back button doesn't work as expected.

I made a workaround for Angular but I would prefer a built-in solution. Anyway, my workaround doesn't yet solve the back button not closing the app, which is annoying.

@Zerokk

This comment has been minimized.

Copy link

commented Jul 18, 2019

It's indeed a very critical issue. We have the same problem: we can't release our app until this functionality is fixed. Hopefully this is ready soon, but anyways, it's great to hear you're on it, @liamdebeasi!

@Dak1411

This comment has been minimized.

Copy link

commented Jul 19, 2019

@AnkitMaheshwariIn

This comment has been minimized.

Copy link

commented Jul 19, 2019

It comes everyday in mind: It's a waste of time to use Ionic Framework - lot's of bugs lot's of issues. And it seems Ionic team have not that much potential to manage issues and resolve on time. They release things before prior testing and that effect our projects.

We have 3-4 products in market - using Ionic from year 2016. We have also taken Ionic paid version Ionic Hub, many more still facing issues in basic things navigation back button, production build etc. etc. listed in above comments by others ( #16611 (comment) )

I request Ionic team to make serious changes in their development strategy and make things better soon because developers are now dependent on your technologies from long time and have no option to move back to other technologies (because project size and team education has already built). That cost much in time and money. Before Ionic seems easy in development (saves time and money) now it becomes double complicated it only ends to frustration.

Thanks/Hope Ionic Team.

@jordankkk

This comment has been minimized.

Copy link

commented Jul 19, 2019

i think ionic team should focus on angular is enough

@ebeliejinfren

This comment has been minimized.

Copy link

commented Jul 19, 2019

really it's take long time

@ionic-team ionic-team locked as off topic and limited conversation to collaborators Jul 19, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.