0

This is a bit of a messy situation that I'll do my best to describe as accurately and briefly as possible.

I have been tasked to maintain an old project. The code is extremely messy and everything is mixed together (One PHP file for every page, and that file contains JS and HTML..)

In that project there is a form to insert new data into the database. The requirement was for a confirmation page to show up after submitting the form, that reflects what the user has input. From that confirmation page the user can either confirm, which would write the data to the database, or go back to the form, and the user has to see all the data he input previously.

One of the fields is a file upload, that has to be an image. If the user decides to upload an image, a few additional fields are to be displayed and made required.

I was tasked to generate a preview for the uploaded image on the form page, and on the confirmation page.

That was easy enough for the form itself..

    const [img] = imgfield.files;
    if (img) {
        imgplaceholder.src = URL.createObjectURL(img);
    }

For the confirmation page, after the user submits the first form, I had the picture uploaded to a scratch folder, that gets scraped regularly, and had the picture displayed from there.

And I had the brilliant idea to do window.history.go(-1) for the button on the confirmation page, that should take the user back to the form.

<label class="navLink" id="changeClick" onclick="window.history.go(-1)">Change</label>

This worked fine on firefox. When the user clicked that link, the browser went back instantly to the previous page, with the user's previous entries still intact, where they could edit them and submit again.

On Chromium-based browsers however, when using this link to go back to the form, the preview of the uploaded image would disappear, and is replaced with the broken image icon, and the fields that should also appear, since the user had uploaded an image previously, also disappear.

What's even more confusing to me is that on firefox, clicking the browser's own back button and this link works exactly the same. Whereby in chrome-based browsers, clicking on the link shows this problem, but clicking on the browser's own back button does not.

So now the question is: why do chrome-based browsers act differently here, and (besides making an entire new hidden form within the confirmation page to send the data back to the form, which would be far too much effort for what this is worth) how to I get that link with history.go(-1) to act like the back button in chromium?

I hope I explained the situation thoroughly enough. I'd be glad to provide any additional details that might be of help.

ProjectEphra
  • 1
  • 1
  • Does this solve your problem? https://stackoverflow.com/questions/16253035/onclick-javascripthistory-go-1-not-working-in-chrome – Costa Jun 14 '21 at 13:14
  • @Costa Hi there, unfortunately no. I had found the post before while I was googling, and had tried what was suggested there, but it made no difference either way. – ProjectEphra Jun 14 '21 at 13:33
  • I tried it in edge (also Chromium-based), but it worked. But I used local HTML pages, not PHP. That might make a difference because PHP output is usually expected to change, so it is not cached. – Iziminza Jun 14 '21 at 13:40
  • You could try `window.history.back()` instead, but I don't really expect a difference... – Iziminza Jun 14 '21 at 13:40
  • @Iziminza have already tried `window.history.back()` and it made no difference. According to MDN it's literally the same as `window.history.go(-1)`. Do you happen to know of any way to force cache a page? – ProjectEphra Jun 14 '21 at 14:05
  • Welcome to BFCache hell™ Here are a few related issues: https://github.com/web-platform-tests/wpt/issues/16359, https://github.com/whatwg/html/search?q=bfcache&type=issues tl;dr; expecting standardized behavior is still asking for too much today, **forcing** BFCache is not really something that is planned (they are more into allowing to disable it), mixing blob:// URLs (which are tied to the Document's lifetime) is very risky (I never saw this case mentioned, while it's obviously a big issue.) – Kaiido Jun 15 '21 at 01:09
  • I might be wrong, but I'd say you'd be better saving the FormData in IndexedDB, before the submission, and populate back your form manually when coming back there. ([You can now also set File objects in file inputs.](https://stackoverflow.com/questions/47119426/how-to-set-file-objects-and-length-property-at-filelist-object-where-the-files-a/47172409#47172409)) – Kaiido Jun 15 '21 at 01:11

0 Answers0