OK,
I'm not an expert in this area, but the fix looks reasonable, and the
API docs work better than before. Like you, I dislike a JavaScript
solution, so while we should go ahead with this for now, let's monitor
the situation to see if this problem gets more attention in the
browsers. I still think the general use of flex containers is a good
idea, even if they have this current drawback.
-- Jon
On 7/16/20 9:10 AM, Hannes Wallnoefer wrote:
Unfortunately I removed a line from my patch that is needed after all. New
webrev and API docs below.
I also added a comment to explain the purpose of the code.
Webrev: http://cr.openjdk.java.net/~hannesw/8249133/webrev.01/
API docs: http://cr.openjdk.java.net/~hannesw/8249133/api.01/
Hannes
Am 16.07.2020 um 16:57 schrieb Hannes Wallnoefer <hannes.wallnoe...@oracle.com>:
Please review:
JBS: https://bugs.openjdk.java.net/browse/JDK-8249133
Webrev: http://cr.openjdk.java.net/~hannesw/8249133/webrev.00/
API docs: http://cr.openjdk.java.net/~hannesw/8249133/api.00/
This patch makes use of the browser History API to add the current scroll
position to the browser history.
Why the scroll position is not recorded in the first place is not entirely
clear to me. It seems to be the combination of flexbox and fixed positioning we
are using that makes the browser assume the scrolling position of our content
area should not be recorder.
I am not too thrilled to solve this problem with JavaScript, but I think I have
explored every other possibility without finding an alternative solution. I
have tested the fix on current Firefox, Safari, and Chrome browsers as well as
the Android browser on my phone. It should be supported on any modern browser
and fully replicates the standard navigation behavior on „normal“ web pages.
Hannes
