Page MenuHomePhabricator

mw.notify should support show on page reload
Open, MediumPublic


MobileFrontend allows us to queue notification messages to display after the page has reloaded. This is useful for displaying toasts after an edit has occurred. Under the hood it creates a localStorage entry that if present will be cleared and trigger a mw.notify message when that's done.

I think this is a useful feature. Having it in MobileFrontend means we can't use it in desktop.

The functionality in MobileFrontend's showOnPageReload.js should be in core. In particular I'm sure it is useful for editing and would DRY up some code.

Event Timeline

Interested in thoughts from growth and editing whether this is a good idea.

I was planning to file something similar but slightly more generic based on MobileFrontend c596013 - in that case, not only the notice but also the hook should ideally be deferred to the next page load. I think it would be nice to have "deferred events" in Javascript where the event includes the name of the ResourceLoader module that handles it, and on next page load that module automatically gets loaded and then the event fired. GrowthExperiments c594780 implements something similar but use-case-specific, and I'd also much prefer that being done once well in core instead.

One nitpick is that sessionStorage IMO usually fits better than localStorage as it makes little sense to do the action in another tab (which happens with localStorage if the user closes the tab before the page has time to reload).

@Tgr this sounds great. Would be happy to use such a think in MobileFrontend! Should we rename the task/description or merge into another task?

Jdlrobson moved this task from Incoming to Triaged but Future on the Readers-Web-Backlog board.

It would be useful to have a short list of some current or upcoming use cases for this to inform the trade-off between maintenance overhead, cost/benefit of abstraction, performance, etc.

I think it is important that we seriously consider and write down how it could work if were to not have any generic implementation in MF or core. This is obviously possible, but what would it look like, what benefits/drawbacks does it involve. There is a tendency to overgeneralise which incurs a lot of costs for both users, staff time, debugging, onboarding.

In core the main use case currently is postEdit, which is currently responsible for calling mw.notify() on its own. Though this use case can't use a generic mechanism as it can't know what to do until the server has processed the edit, after which point we're already on the new page and thus don't need a reload. It sends information about what to display in a cookie. This has the benefit of not loading unused code, not causing synchronous I/O on every page view, and allows localisation, HTML templates, custom styles, etc. which a generic implementation would need to know how to obtain or store.

If we do generalise, I would strongly recommend that it still be triggered through a query parameter or cookie of sorts, even if only to tell it to look somewhere else.