Two history records are saved when the link contains a client-side redirect
Categories
(Toolkit :: Places, defect, P3)
Tracking
()
People
(Reporter: xuyuehang, Unassigned)
Details
Attachments
(2 files)
history record
Feedback from users, when the visited link has a redirect, both the redirect url and the real url will be saved in the history record. This can cause certain difficulties when looking up history. Other browsers only save real url.
For example, to access the search results of google, see the attachment. This problem can be reproduced in Instagram, Twitter, or shopping guide websites that contain redirects.
|
||
Comment 1•5 years ago
|
||
We are supposed to record the redirect, but the source should be hidden by default in the view. It may depend on the level or way the redirection happens, for example HSTS is not handled correctly atm, as explained in bug 1520173. I don't think this is the HSTS case because afaict this is all https handling.
I tried to reproduce the bug but I couldn't, and I don't see http redirects, but it's possible due to me being in a different region, indeed I never see a visit to a /url[...] path.
It would be useful to have some kind of network log, you could use the Network pane from DevTools to check which headers and http status are sent by that /url page, it would be useful to know if it's a GET or POST, a 30X redirect or done through code, and so on. If you don't know how to do that we can try to provider further steps to help. You can find some documentation of the network monitor at https://developer.mozilla.org/en-US/docs/Tools/Network_Monitor and https://developer.mozilla.org/en-US/docs/Tools/Network_Monitor/request_details, I'm mostly interested in the urls and headers from Google.
Thanks Marco. In the above example of accessing the wiki from the Google search results, I found that the webpage did not appear 30X jumps, but there were two 200 requests respectively. Which is the URL of the two records shown in the history.
You can visit: https://www.google.com.hk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwjwqMOFud_xAhVEhMYKHSJ7DVkQFnoECB0QAA&url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FTest&usg=AOvVaw3h70I8hfgutLRH9tV7Y8uF
Right click to copy the Wikipedia link in google search results to reproduce this problem. The address of this link is https, so I think it should not be the case of bug 1520173.
I looked for another example with a 302 jump link: https://go.smzdm.com/0edd0479a386b723/ca_aa_yh_27_36202288_12257_37109_29_0
Visiting this website will record three pieces in history, namely 'www.linkstars.com/xxx', '正在跳转至购买页面', and the real address.
The above two URLs are accessed in chrome, and only the real address is saved in history.
|
|
||
Comment 3•5 years ago
|
||
We save everything to history, what should change is what we show by default in the history views: redirect sources should be hidden.
But, if you search history (by typing any search terms), then redirect sources will also be shown. I think this is an important difference to keep in mind.
I still think there is a bug here because, as I said, by default we should only show the final url.
Now, it's interesting that the initial request is a GET with a 200 HTTP status, likely redirecting through some client side code. history wouldn't detect that properly. In my case (my region) from google.com.hk I see a 200 POST, followed by a 204 url. Those don't appear in history views.
If this redirect is done through client side code, I suspect detecting this case to fix the bug may not be trivial.
Description
•