amp-lightbox not working after browser back, requires page reload

[88kbbq]

I'm testing the use of amp-lightbox to display a full-viewport navigation menu on mobile devices. Links in the amp-lightbox navigate to pages as expected, but when testing, the <button on="tap:my-lightbox">Open lightbox</button> does not function as expected after returning to the page using the browser back button. The amp-lightbox button simply doesn't open the amp-lightbox. After the page is refreshed, the amp-lightbox will open as expected.

[dvoytenko]

@sriramkrish85 could you take a look?

[camelburrito]

@88kbbq is there a page i can look at? I tried this in the some manual test files seems to be working.

[88kbbq]

Just uploaded to pos.88k.com.tw. I'll add some other pages, but it seems if the page doesn't have the lightbox.js then the lightbox won't open/close unless the page is reloaded. For testing, the catering.html has the lighbox.js but the restaurant.html does not. Also, the lightbox doesn't close if the user navigates to another page without closing the lighbox. Not sure how to implement the hamburger-style menu dropdown with AMPHTML, but if there's a better way just point me to those resources.

[88kbbq]

Maybe there could be a `on="tap:my-lightbox.reset"' that resets lightbox to default state after tapping a link

[88kbbq]

working around these AMP HTML restrictions is just a nightmare. How about you allow 50,000 bytes of inline JS like the 50,000 bytes amp-custom CSS? Restrict those functions that conflict with the v0.js and you could solve half the problems on Github in one fell swoop without a signification impact on page load speed. Consider? I mean, even GPRS gets 0.1Mb/s, so what's a split second really when an image would take just as much, if not longer? You could restrict it to before the </body> tag.

[rudygalfi]

@sriramkrish85 Can you test back button scenarios in top window and iframe? Close this out if no further action is needed.

The rest covered here will be addressed by menu work.

[88kbbq]

Tested a bit, so far so good. Closing the amp-lightbox problem, but hopefully a menu option will be available soon.

[johndsci]

btw, this is still present in 2021.
amp-lightbox still not working on browser back.
everything works on desktop.
now working on mobile (tested using safari 14.4, chrome 87 app)

the only workaround is to use on="tap:AMP.navigateTo(url='some_url')" instead of href

[dvoytenko]

@johndsci I've tried the examples listed here: https://amp.dev/documentation/examples/components/amp-lightbox/?format=websites and they all appear to work correctly with the back button. Is the situation you're describing somehow different?

[johndsci]

@dvoytenko I used amp-lighbox for a much cleaner alternative to sidebar nav.

users will navigate the pages by clicking some hamburger icon on the top which opens the lightbox with links inside. clicking the links would navigate to another page.

when on the next page, the browser's back option would bring you back to the previous page with the lighbox already opened and all buttons and links not working. you need to refresh the page again for everything to work.

everything's fine on desktop.
mobile browsers broken.

[dvoytenko]

/cc @caroqliu this is an interesting case. There's a special navigation handler inside the sidebar that resolves history conflicts on navigation to avoid back button issues there. Perhaps we could make it available to all other overlaying components? And that also brings up the fact that we should probably also consider it for Bento?

/cc @ampproject/wg-components

[caroqliu]

There's a special navigation handler inside the sidebar that resolves history conflicts on navigation to avoid back button issues there.

@dvoytenko Are you referring to the following introduced due to #6585?:

amphtml/extensions/amp-sidebar/0.1/amp-sidebar.js

Lines 274 to 288 in 8058170

	if (target && target.href) {
	const tgtLoc = Services.urlForDoc(element).parse(target.href);
	const currentHref = this.getAmpDoc().getUrl();
	// Important: Only close sidebar (and hence pop sidebar history entry)
	// when navigating locally, Chrome might cancel navigation request
	// due to after-navigation history manipulation inside a timer callback.
	// See this issue for more details:
	// https://github.com/ampproject/amphtml/issues/6585
	if (removeFragment(target.href) != removeFragment(currentHref)) {
	return;
	}
	if (tgtLoc.hash) {
	// Click gesture is high trust.
	this.close_(ActionTrust.HIGH);
	}

Trying to think if there are other overlaying components to consider here... amp-consent, and maybe amp-sticky-ad? Do @ampproject/wg-stories folks have any overlaying components that manipulate history more directly? Would be good to know what others do if so.

[gmajoulet]

We do for Stories, and do it a different way:

1. When opening the overlaying component, we push a new history entry, and:
   a. add some data to the history entry so we remember it's open in case of page reload.
   b. register a method to close it when that entry is popped

amphtml/extensions/amp-story/1.0/amp-story-page-attachment.js

Lines 255 to 264 in 8058170

	const currentHistoryState = /** @type {!Object} */ (getState(
	this.win.history
	));
	const historyState = {
	...currentHistoryState,
	[HistoryState.ATTACHMENT_PAGE_ID]: this.storeService_.get(
	StateProperty.CURRENT_PAGE_ID
	),
	};
	this.historyService_.push(() => this.closeInternal_(), historyState);

2. The overlaying component can be closed by:
   a. a user navigating back, which will pop the history entry and call the callback we provided above
   b. a user interaction on the page, in which case we call history.back() manually, to pop the history entry and trigger its callback

amphtml/extensions/amp-story/1.0/amp-story-page-attachment.js

Line 314 in 8058170

this.historyService_.goBack();

[dvoytenko]

@gmajoulet it sounds like you're trying to keep the overlay UI on refresh of the page? This doesn't always work well with all types of overlaying UI. Though it might be ok for us here.

@caroqliu, yes, that's the one I mean. We could always do it differently, of course, e.g. closer to what @gmajoulet, which avoids popping history on navigation. I think that could be ok as well for this use case. But then you have a choice of:

1. Either restoring the lightbox when a user returns to the page.
2. Not restoring the lightbox and just simply "living with" a dead history state.