[konqueror] [Bug 467850] Browsing history is not proper in some sites
https://bugs.kde.org/show_bug.cgi?id=467850 Stefano Crocco changed: What|Removed |Added Resolution|--- |FIXED Latest Commit||https://invent.kde.org/netw ||ork/konqueror/-/commit/ae2a ||79e933fe6dc7be87a5142a7514c ||1513a1eb5 Status|ASSIGNED|RESOLVED --- Comment #7 from Stefano Crocco --- Git commit ae2a79e933fe6dc7be87a5142a7514c1513a1eb5 by Stefano Crocco. Committed on 21/04/2024 at 08:18. Pushed by stefanocrocco into branch 'master'. Fix history when there's an URL change without a corresponding loadStarted signal This happens, for example, when the page uses the history API to trigger a navigation. See https://bugreports.qt.io/browse/QTBUG-115589. M +1-2src/konqview.cpp M +20 -1webenginepart/src/webenginepart.cpp M +34 -1webenginepart/src/webenginepart.h M +19 -2webenginepart/src/webenginepart_ext.cpp M +27 -0webenginepart/src/webenginepart_ext.h https://invent.kde.org/network/konqueror/-/commit/ae2a79e933fe6dc7be87a5142a7514c1513a1eb5 -- You are receiving this mail because: You are watching all bug changes.
[konqueror] [Bug 467850] Browsing history is not proper in some sites
https://bugs.kde.org/show_bug.cgi?id=467850 Bug Janitor Service changed: What|Removed |Added Status|CONFIRMED |ASSIGNED --- Comment #6 from Bug Janitor Service --- A possibly relevant merge request was started @ https://invent.kde.org/network/konqueror/-/merge_requests/319 -- You are receiving this mail because: You are watching all bug changes.
[konqueror] [Bug 467850] Browsing history is not proper in some sites
https://bugs.kde.org/show_bug.cgi?id=467850 --- Comment #5 from avlas --- (In reply to Stefano Crocco from comment #4) > (In reply to avlas from comment #3) > > > Hmm, what do they mean by the page remains the same? I don't get it. The URL > > is different and the content is too. I can see how konqueror loads the new > > content with the progress bar. > > According to their answer, GitHub uses the History API > (https://developer.mozilla.org/en-US/docs/Web/API/History_API), in > particular the pushState and/or replaceState methods. They allow the web > page to simulate navigating to a new URL without actually doing so. > According to the Chromium documentation (on which QtWebEngine is based), > this isn't treated as navigating to a new page > (https://chromium.googlesource.com/chromium/src/+/main/docs/ > navigation_concepts.md#Same_Document-and-Cross_Document-Navigations). This > is treated the same way navigating to another fragment (the part after the # > of an URL) of the current document is. Unfortunately, from the user's point > of view this is rather unintuitive (unlike the fragment case, where it's > clear that we're still in the same page). > > By the way, when clicking on the pull requests link from > https://github.com/KDE/konqueror I don't see the progress bar in Konqueror > (the one on the bottom right of the status bar), but only a thin progress > bar at the top of the page which is provided by the GitHub page itself. Oh I see the problem now, thank you -- You are receiving this mail because: You are watching all bug changes.
[konqueror] [Bug 467850] Browsing history is not proper in some sites
https://bugs.kde.org/show_bug.cgi?id=467850 --- Comment #4 from Stefano Crocco --- (In reply to avlas from comment #3) > Hmm, what do they mean by the page remains the same? I don't get it. The URL > is different and the content is too. I can see how konqueror loads the new > content with the progress bar. According to their answer, GitHub uses the History API (https://developer.mozilla.org/en-US/docs/Web/API/History_API), in particular the pushState and/or replaceState methods. They allow the web page to simulate navigating to a new URL without actually doing so. According to the Chromium documentation (on which QtWebEngine is based), this isn't treated as navigating to a new page (https://chromium.googlesource.com/chromium/src/+/main/docs/navigation_concepts.md#Same_Document-and-Cross_Document-Navigations). This is treated the same way navigating to another fragment (the part after the # of an URL) of the current document is. Unfortunately, from the user's point of view this is rather unintuitive (unlike the fragment case, where it's clear that we're still in the same page). By the way, when clicking on the pull requests link from https://github.com/KDE/konqueror I don't see the progress bar in Konqueror (the one on the bottom right of the status bar), but only a thin progress bar at the top of the page which is provided by the GitHub page itself. -- You are receiving this mail because: You are watching all bug changes.
[konqueror] [Bug 467850] Browsing history is not proper in some sites
https://bugs.kde.org/show_bug.cgi?id=467850 --- Comment #3 from avlas --- (In reply to Stefano Crocco from comment #2) > (In reply to Stefano Crocco from comment #1) > > (In reply to avlas from comment #0) > > > SUMMARY > > > > > > History fails to remember internal browsing in some sites such as GitHub. > > > It > > > works fine in other browsers such as Firefox > > > > > > STEPS TO REPRODUCE > > > 1. open a new tab > > > 2. go to https://github.com/KDE/konqueror > > > 3. click on pull requests (it moves to > > > https://github.com/KDE/konqueror/pulls) > > > 4. go back (button or alt+left) > > > > > > OBSERVED RESULT > > > > > > it comes back to new tab > > > > > > EXPECTED RESULT > > > > > > it should go back to https://github.com/KDE/konqueror instead > > > > This is caused by the underlying web engine (QtWebEngine) not informing > > Konqueror that a new page has been loaded. I created a bug report for > > QtWebEngine (https://bugreports.qt.io/browse/QTBUG-115589), because I think > > this is not supposed to happen: let's see if it gets some answers. > > > > Unfortunately, working around this issue would either require heavy changes > > in the way Konqueror manages history or using different ways to detect that > > a different page has been loaded, which could have unwanted side effects. > > I'll wait for some answers to my bug report before trying any of these > > workarounds. > > According to Qt, this is not a bug because even if the URL changes, the page > actually > remains the same. This means that I'll have to find out how to change how > WebEnginePart > handles history to account for situations like this. I fear it won't be > easy: I already tried the > most obvious approach (reacting to the change in the URL rather than to the > loading of a > new page) but it doesn't work. Hmm, what do they mean by the page remains the same? I don't get it. The URL is different and the content is too. I can see how konqueror loads the new content with the progress bar. -- You are receiving this mail because: You are watching all bug changes.
[konqueror] [Bug 467850] Browsing history is not proper in some sites
https://bugs.kde.org/show_bug.cgi?id=467850 --- Comment #2 from Stefano Crocco --- (In reply to Stefano Crocco from comment #1) > (In reply to avlas from comment #0) > > SUMMARY > > > > History fails to remember internal browsing in some sites such as GitHub. It > > works fine in other browsers such as Firefox > > > > STEPS TO REPRODUCE > > 1. open a new tab > > 2. go to https://github.com/KDE/konqueror > > 3. click on pull requests (it moves to > > https://github.com/KDE/konqueror/pulls) > > 4. go back (button or alt+left) > > > > OBSERVED RESULT > > > > it comes back to new tab > > > > EXPECTED RESULT > > > > it should go back to https://github.com/KDE/konqueror instead > > This is caused by the underlying web engine (QtWebEngine) not informing > Konqueror that a new page has been loaded. I created a bug report for > QtWebEngine (https://bugreports.qt.io/browse/QTBUG-115589), because I think > this is not supposed to happen: let's see if it gets some answers. > > Unfortunately, working around this issue would either require heavy changes > in the way Konqueror manages history or using different ways to detect that > a different page has been loaded, which could have unwanted side effects. > I'll wait for some answers to my bug report before trying any of these > workarounds. According to Qt, this is not a bug because even if the URL changes, the page actually remains the same. This means that I'll have to find out how to change how WebEnginePart handles history to account for situations like this. I fear it won't be easy: I already tried the most obvious approach (reacting to the change in the URL rather than to the loading of a new page) but it doesn't work. -- You are receiving this mail because: You are watching all bug changes.
[konqueror] [Bug 467850] Browsing history is not proper in some sites
https://bugs.kde.org/show_bug.cgi?id=467850 --- Comment #1 from Stefano Crocco --- (In reply to avlas from comment #0) > SUMMARY > > History fails to remember internal browsing in some sites such as GitHub. It > works fine in other browsers such as Firefox > > STEPS TO REPRODUCE > 1. open a new tab > 2. go to https://github.com/KDE/konqueror > 3. click on pull requests (it moves to > https://github.com/KDE/konqueror/pulls) > 4. go back (button or alt+left) > > OBSERVED RESULT > > it comes back to new tab > > EXPECTED RESULT > > it should go back to https://github.com/KDE/konqueror instead This is caused by the underlying web engine (QtWebEngine) not informing Konqueror that a new page has been loaded. I created a bug report for QtWebEngine (https://bugreports.qt.io/browse/QTBUG-115589), because I think this is not supposed to happen: let's see if it gets some answers. Unfortunately, working around this issue would either require heavy changes in the way Konqueror manages history or using different ways to detect that a different page has been loaded, which could have unwanted side effects. I'll wait for some answers to my bug report before trying any of these workarounds. -- You are receiving this mail because: You are watching all bug changes.
[konqueror] [Bug 467850] Browsing history is not proper in some sites
https://bugs.kde.org/show_bug.cgi?id=467850 Stefano Crocco changed: What|Removed |Added CC||stefano.cro...@alice.it Status|REPORTED|CONFIRMED Ever confirmed|0 |1 -- You are receiving this mail because: You are watching all bug changes.
