Amphtml: Proper `goback` functionality in AMP

[keepitsimple]

UPDATE [May 14 2020]
I'm pretty sure that the AMP team will spent another 5 years on decision "TO DO vs NOT TO DO". The workaround is simple - use iframe with JS code inside which calls history.back. Yes it's ugly but it works.

---

Can you please add some param for <button> or <a> tags which will do javascript:window.history.back() call?

I use amp-iframe as workaround for this issue, but it will be much more convenient to have dedicated "amp-" tag for it or an attribute for <button> or <a> tags.

Thank you in advance

[camelburrito]

@ericlindley-g lets start a discussion on this here. This seems like a valid request.

[Gregable]

We could use the validator to whitelist a very specific javascript: URL for some href values.

[ericlindley-g]

I agree that this seems like a valid request—is there any risk of abuse here? Can we define the validation narrowly enough that it would strictly allow only forward and back navigation?

Also, I'm assuming that in the viewer context this just behaves exactly as the back button would, dismissing the viewer. (?)

[dvoytenko]

All, this sounds like a very legitimate request but with some nuances.

@Gregable, I think we'll just continue using our on actions. Something like <a on="tap:history.back">.

@ericlindley-g, I'd like to hear more on this. But I'd ideally like to avoid going over viewer/document boundary. I.e. ideally I'd see this action going back in history for the document only: close lightbox, back to top, etc.

[ericlindley-g]

@dvoytenko That makes a lot of sense—on reflection, it seems like the use-cases for an additional UI element in the document itself that navigates history back would only make sense within the context of that document, anyway, and not have particular need to close the viewer.

[dvoytenko]

Sounds good, in this case, I suggest the format be:

<a on="tap:AMP.goBack">

[keepitsimple]

Ping :)

[dvoytenko]

@ericlindley-g Let's schedule it soon?

[ericlindley-g]

@dvoytenko Will do — we can schedule w/r/t the bandwidth of core AMP contributors.

And to developers in the broader AMP community—this might be a straightforward enough feature to be a good starter contribution :)

[keepitsimple]

@dvoytenko I checked in the releases. And it looks like the feature must be available by default. But it doesn't work for me. But in the same time it path through validation
<button class="btn btn-default circle nob" on="tap:AMP.goBack"><span class="domicon domicon-arrow-long-left t5"></span></button>

[jridgewell]

@keepitsimple Can you open another issue with a page that reproduces?

[dvoytenko]

@keepitsimple This should be released now everywhere. Please just ping the reproducing URL here and I'll take a look. As we discussed, at this time the navigation back is only done in the history stack of the document itself, not outside it.

[keepitsimple]

@dvoytenko Here you are: http://m.domino.com/main/issue1
Please click on the link on the page; then click a back icon.

[dvoytenko]

@keepitsimple I see. You actually want to back button to navigate between different pages. The current implementation stays within the boundary of each document. This is what I meant by:

But I'd ideally like to avoid going over viewer/document boundary. I.e. ideally I'd see this action going back in history for the document only: close lightbox, back to top, etc.

I'll check on what security measures we need to go across the boundary of multiple documents.

[dvoytenko]

I scheduled this for a wide audience for this week's design review (#7380). Please join if you can.

[dvoytenko]

Based on yesterday's Design Review (#7380), some feedback from participants:

1. It appears that the ask is to allow back-nav outside of the context of the current document. This is likely a separate API from AMP.goBack.
2. This has challenges with embedding AMP docs, which includes:
   a. The behavior of this button would differ for depending on whether back-nav is possible. E.g. with no history stack, this will be a non-functional UI.
   b. The parent app could be forced to close AMP viewer.
3. One option is to disallow back navigation when the document is embedded. This is undesirable as it would show a non-function UI.

Couple of solutions proposed instead:

1. A self-replacing navigation: <a data-replace=true href="./...">. Instead of using history.back, we'd purge intermediate history stack and replace the current page with the provided URL.
2. Look into more sophisticated flows, including form submits to come up with back API, e.g. involving directing query params.

Any feedback on this feedback?

[vamshi5889]

Are we going forward on this? I feel like having the browser back button action is really helpful.

[AcidRaZor]

Do we still have no meaningful way to go back to the previous page? The concern with point 2.b in the feedback of the feedback is how browsers currently function. So a normal user, hitting the back button like a crazy person, would get to the home/empty tab screen regardless if they were using an amp button to tap or their phone or their mouse.

From a UX standpoint, it is quite fundamental to give us the ability to add a back button without having to break validation by adding JS or using work-arounds like iframe or force developers into custom-database tables to keep track of user movements just so they could use XHR posts to their API's to redirect users effectively.

Would love some movement on this topic because I feel if we can't get basic UX functionality (including navigation users are used to seeing on mobile designs by now), it just makes adoption of this technology superficial to the point where watered-down AMP pages are used just because google search gives them more preference in rankings, which really craps all over the UX (I've seen it with quite a few implementations on the web currently)

Hope @aghassemi doesn't think I'm being too aggressive with my post :)

[aghassemi]

Hi @AcidRaZor We have AMP.goBack action already supported. It works with both normal navigations and amp-bind's AMP.pushState(). Sorry for not updating this ticket when that feature was added.

[aghassemi]

Closing the issue as AMP.goBack action has been already implemented.

[AcidRaZor]

Thanks @aghassemi

I'm probably doing something dumb, because on="tap:AMP.goBack" does not seem to navigate back in history?

[aghassemi]

@AcidRaZor you are correct goBack does not work across multiple documents. Reopening.

@dvoytenko any objection on extending AMP.goBack with an optional param to perform x-document back navigation? (e.g. AMP.goBack(AllowAcrossDoc=true))

[keepitsimple]

2 years passed but the problem is not resolved yet.

[dvoytenko]

@aghassemi As I described above, there's definitely no good consensus on cross-document back navigation for this API (and definitely not cross-origin). Too many embedded environments where this would simply lead to broken UX. Unfortunately, the Web History API is not great for this kind of cases. We could do some work to compensate for this, but we won't be able to fully eliminate UX problems.

[AcidRaZor]

@dvoytenko The fact that there is no easy way for dev's who implement this API to do a simple history.back is what is ruining the UX at the end of the day when that dev doesn't know how to do a work-around to give his web app the ability to do something that 100% of other websites can do.

Maybe we should focus on UX instead of the nuances surrounding the google CDN and cross-origin and "embedded environments".

I really don't care to be on the CDN or getting the google-gods to give me higher rankings, I care about fast loading great user experience for my users... was I misled into thinking that this is what the focus was on for this project...?

Regardless, let's focus on what you said "above", be a bit more constructive:

1) Possibly, and agreed, perhaps a separate API or even component is required.

2a) How would this differ to ANY back button currently in ANY UX? When there is no history stack, the button is grayed out and stops functioning. Much like how non-functioning UI elements on Chrome (top left) grays out when there is no history? Users are already used to this. Why complicate it?

2b) Yes. That's exactly the behavior of any app that I have ever used. If I hit my back button like a fiend, eventually it will close it. As an example, open your phone's Chrome. If you have a page there that was left over from a google search or several clicks. Start hitting the back button (on my S7 Edge I'm doing it with the button to the right of the home button). Keep tapping the back button. When Chrome gets to the starting point of where it was opened initially, i.e, no history stack, THE ENTIRE APP closes when you hit the back button again. Perfectly normal and acceptable and adopted by millions of users world-wide as the defacto standard of what happens when they go back-button insane, some apps even ask if I am sure that I want to exit.

1. Being embedded shouldn't be the standard we're looking at and the reason why we can't have nice things. UX and speed should be the focus. As mentioned, I personally don't care about being on the CDN or even care for the rankings boosts. Speed is speed is a great start for UX.

What I would suggest though, is the AMP Viewer or whatever embeds the document, can interact with the AMP page, perhaps intercept and marshal the "back" command. Now I don't have in-depth knowledge or how the AMP API is working, or even pretend to know as I'm usually busy with loads of other things. But when I want cross-origin messages to be passed between iframe and parent, I use HTML5's send message feature. Surely whatever embed's the page should have the same thing going to be able to help the one communicate with the other?

Regardless. I really don't understand why it's taking 2 years for a back button, something fundamental to the web that all users know about, and something, when left out because I couldn't find a viable alternative, is pointed out very quickly when doing user-focus groups. My head almost exploded when I heard the first few people ask where the back button was...

Hope you find my comments constructive and not attacking. aghassemi can point out if I was being harsh or evil with what I'm saying... or I can be a total moron and be wrong about everything and how I view things, in which case I'm always open to be enlightened.

[aghassemi]

@AcidRaZor, Thanks for the feedback. I agree that the nuances here should not impact you having access to some of the basic JS APIs.

We are already considering adding AMP.windowClose for a similar case ( https://github.com/ampproject/amphtml/issues/19683 ). I don't see this being different. We can clarify through the API that this is different than AMP.goBack and is directly tied to browser's back behaviour.

@dvoytenko Unless any objections, I like to go ahead and add both AMP.windowClose and AMP.windowBack. The naming prefix and documentation would clarifies these are equivalent to window.close and history.back.

[dvoytenko]

@aghassemi I'm generally ok with either way we proceed. Just calling out that the fit with the initial API that's already there.

But I do want to say that embedding cases are a critical promise of AMP and we need to make sure we do not break those guarantees to viewers with the new APIs.

[leonalicious]

@AcidRaZor @keepitsimple hey guys, chill out, I can definitely feel the heat from your guys. AMP Team is working really hard to make Web Development easier and we can all surely benefit from it in a long-term run, all we need is keep providing our ideas and use cases to them as we are the closest user to their product ever.

@dvoytenko @aghassemi Guys, what do your guys think about amp-script ? actually amp-script is a general more universal solution to solve our needs in accessing HTML APIs including these window.close or history.back or whatever we needs in future.

[choumx]

Another FR for this: #21260

Note that amp-script won't initially have ability to modify page history state.

[amanintech]

Another FR for this: #22921

[choumx]

This FR needs a new owner.

@dvoytenko Why shouldn't the viewer close here? Is the concern exiting viewer carousels? Closing seems fine for single-page viewers and is most consistent with non-AMP.

[dvoytenko]

This is just a question of consistency in standalone site vs viewer vs native app viewer.

[samouri]

Is there any reason the action for AMP.windowBack wasn't added? If this is something we still want, I'd be happy to work on it

[dvoytenko]

I think goBack or other history.back or any other should be ok. The main requirement for this action is to require user gesture.

[vtisnado]

Hey guys, any update or workaround about this?

[keepitsimple]

@vtisnado Forget about it until 2040 :)

As a workaround I used iframe with JS code where I called history.back.Yes it's ugly but it works

[saipulbacry]

https://github.com/users/saipulbacry/emails/106013097/confirm_verification/878b90f454cc40c13805269e772c80f21cda373f?utm_campaign=github-email-verification&utm_content=html&utm_medium=email&utm_source=verification-email

[AcidRaZor]

@keepitsimple On a side note, we decided to move to ReactJS with server-side rendering and Cloudflare caching. Our application is now feature-rich and on-par in terms of speed and load time on mobile devices compared to AMP. Weird to see this topic pop up again and be re-opened. 2020 has been a weird year thus far