After clicking the back arrow in Microsoft Edge, my JavaScript runs once again. But there’s a BIG problem!
The values returned by “getElementById(“options”).value” are NOT the correct values for the option that is visible from the dropdown selection.
Firefox and Safari don’t have this problem, so why is Microsoft Edge and Chrome still Buggy after all these years? And therefore how can I overcome this mismatch between the returned getElementById().value and the visibly selected option?
Why does this matter? Because I’m sending dropdown selected values to the server-side via AJAX for an ecommerce shopping cart, and so the returned value needs to match the visible selection for the given dropdown before being sent over.
Naturally customers will occasionally click on the back arrow, and when they do, various values don’t always match with the visible selection – the exact mismatch depends on the particular browser.
So, after detecting that the page has been landed on by the user having clicked the back arrow, I then simply call getElementById().value for all of the dropdowns on the page, pass the values to the server via AJAX, and then use the newly calculated values that are returned by AJAX to refresh the page – a solution that works perfectly for Firefox and Safari, but NOT for Edge and Chrome.
Therefore, I’ve created a small test program that demonstrates the problem perfectly. You’ll notice that I’ve included the code (two HTML files), and a 33 second video which shows the test program running, with Edge on the left and Firefox on the right.
As shown in the video, the steps to reproduce the issue are as follows…
- Select option 2
- Navigate to page 2 by clicking the link
- Click the back arrow
Here’s the video: https://youtu.be/J3tLFXjPDdA
Can you see the problem? within window.onload, getElementById(“options”).value returns “option-1” after clicking back arrow, which does NOT match the selected option “Option 2” that is visible.
Bizarrely, I then discovered that just by delaying the call to getElementById() by setting setTimeout(), the value returned then becomes “option-2” which IS Correct, even for a delay value of 0.
I don’t want to simply reload the page on back arrow as a fix. I’d much rather learn why this mismatch of visible selection vs returned value is happening? If you think this is technically NOT a BUG, then please, I’d love to hear your explanation!
To run the test program, for each of the two pages simply copy the code into a text file and change the extension to .htm, and then right click on …page-1.htm and select open with Edge.
<!DOCTYPE html>
<label for="options">Select Option</label>
<select id="options">
<option value="option-1">Option 1</option>
<option value="option-2">Option 2</option>
</select>
<a href="back-arrow-issue-page-2.htm">Page 2</a>
<script>
window.onpageshow = function(event) // testing for bfcache
{
if (event.persisted)
alert("From bfcache");
};
window.onunload = function(){}; // disables bfcache in Firefox when running an htm file from a local drive, so that the script will run for a second time, i.e. after clicking back arrow. Note: this doesn't disable bfcache when running a local htm file in Safari
window.onload = function()
{
console.log("in: window.onload");
let performance_entries = performance.getEntriesByType("navigation");
for (var i = 0; i < performance_entries.length; ++i)
{
console.log(performance_entries[i].type);
if (performance_entries[i].type == "back_forward")
{
console.log(document.getElementById("options").value);
setTimeout(delay_test, 0); // 1 worked, and so I then tried 0 which also works
}
}
function delay_test()
{
console.log(document.getElementById("options").value);
}
}
</script>
<!DOCTYPE html>
<a href="back-arrow-issue-page-1.htm">Page 1</a>
Cheers, Gary.