If the issue is to react to an event that gets triggered with the back button (and not pageLoad), we could use the pageShow event.
That might look something like this

$(window).on("pageshow", function(event) {
    if (event.originalEvent.persisted) {
        $( '#content p, .content p' ).css( 'font-size', userFontSize + '%' );
    }
});

Jan yeh that sounds like it might work. Are you or anyone else able to investigate and verify whether that works for this particular scenario? If not I'll take a look tomorrow.

Change 405233 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/extensions/MobileFrontend@specialpages] Update the font size on back button presses

https://gerrit.wikimedia.org/r/405233

whoo!

https://gerrit.wikimedia.org/r/405233 is still awaiting for reviewing.

Change 407047 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/extensions/MobileFrontend@master] Update the font size on back button presses

https://gerrit.wikimedia.org/r/407047

Change 407047 abandoned by Jdlrobson:
Update the font size on back button presses

https://gerrit.wikimedia.org/r/407047

Change 405233 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@specialpages] Update the font size on back button presses

https://gerrit.wikimedia.org/r/405233

The new behaviour is testable on reading web staging. https://reading-web-staging.wmflabs.org/wiki/Special:MobileOptions

Took a long look at Staging today and found that it seems to work well except in a few instances.

I am having troubles when switching from the large and x-large sizes to small. Here are some steps and a short video:

Steps:

1. Load an article
2. Tap settings
3. Change font to X-large
4. Tap back and view the article
5. Tap settings
6. Change to Small
7. Tap back and view the article

Result:
Font does not change

Note - It seems to happen most often going from X-large to small. I have occasionally seen it going from other sizes to small. The frequency is like 3/5.

I'm not sure if there's much more we can do here :/ Is it fair to say this is iOS specific?

Yes, I cannot repro this issue on android

In T185166#3939140, @Jdlrobson wrote:

I'm not sure if there's much more we can do here :/ Is it fair to say this is iOS specific?

do we know what might be causing this?

No i'm a bit lost now, as it seemed to be working when I was testing and we're now updating the font changer whenever the page is shown.

Will need more than 2hrs to investigate what's going on (maybe a day). Will need some real devices, the specific iOS version where it's happening and browser (either Chrome or iOS Safari).

Is this big enough of a problem to block the deploy?

Wouldn't consider it a blocker, but some more information would be helpful. @ABorbaWMF - would you mind looking through a number of devices and iOS versions (browsers? or are we sure that it's just Chrome)?

I've been able to reproduce the issue on following, but is not consistently happening:

iPhone X iOS 11 - Safari
iPhone 8 iOS 11 - Safari
iPhone 6s iOS 9 - Safari & Chrome & Firefox - Does NOT happen on UC Browser

I have not reproduced it on Android at all

Okay, looking into this this is looks like it's related to how the back-forward cache works and a bug in Safari.
There appears to be a potential fix but its labelled as a hack (https://stackoverflow.com/a/37011941/466856) and after a bit of experimentation I cannot reliably get it to work :/ I would advise against trying this. Even if we can fix it on the short term there is no guarantee it will work in feature.
The same problem is what makes the menu stay open after you click the back button.

How do you want to handle this Olga?
It seems like a good option would be to avoid the user having to click back somehow... not sure if Nirzar has any good ideas there.

filed under T187170: Font changer does not save changes consistently on mobile web