Originally Posted by
dunk
The cookie policy addresses this directly ...
Actually it doesn't!
That is talking about remembering your chosen departure airport when changing pages, so that new instances of the booking form have the previous choice pre selected.
And in this case, for the avoidance of doubt, the departure airport did not change anyway.
Cookies are sent back to the site that created them, regardless of multiple tabs.
Indeed, they are certainly cross tab in nature.
However no booking system should behave as this one did. And even though it behaved this way, it would not be using cookies in any fashion that would cause this behaviour. Cookies are a redherring.
The core point:
Lets say you do have situation (either in the new booking pages, or in Chrome browser rather than the other browsers I've used) where doing simply a headline availability check affects something in another tab that is already advanced towards the final screens checkout screens.
IF that is the situation, your system should notice the that a timestamp for the basked state when the submission form was generated (and returned with the submission form upon hitting the button), the time stamp for the state does not match the timestamp for the basket state now in the system.
You should return to the user for reconfirm.
Users should be able to expect behaviour of a site to be constant across the major browsers.
But I'm not ruling out a design change to the booking pages either.