2052799 - Some challenge pages use POST to reach the final page, then History is not storing the final title because it skips POST visits

Status: RESOLVED FIXED

(Toolkit :: Places, defect, P2)

Description

[Marco Bonardo [:mak]]

The page shown as example in Bug 2051805, https://encode.su/forums/2-Data-Compression, uses a robot challange that redirects using replaceState.
In my case if first replaceState to a localized challenge page, then it forwards to the final forum page.
Chrome shows 3 history entires, "Just a moment", "Ci siamo quasi", "Data compression".
Firefox only shows the challenge titles, doesn't show a visit for the final title.

Comment 1

[Artem S. Tashkinov]

The challenge flow changes the current history entry with history.replaceState(), then performs a further navigation to the final document. Firefox records the intermediate titles but fails to record/update the final document title.

Comment 2

[Marco Bonardo [:mak]]

Once the challenge is solved, the browser submits a form POST to encode.su/forums/2-Data-Compression?__cf_chl_f_tk=…, and Cloudflare responds with the actual page content (HTTP 200, no redirect).

Firefox has a long-standing rule that POST navigation results are excluded from global history (Places). Because the form POST received a direct 200 response rather than a PRG redirect, DocumentLoadListener::RedirectToRealChannel skipped AddURIVisit for the final URL. The URL was never inserted into moz_places.

When the page title "Data Compression" was set, UpdateGlobalHistoryTitle sent a SetURITitle IPC to the Places DB thread, but SetPageTitle::Run found exists=0 — no entry for the URL — and silently dropped the title update.

The result: the final URL never appears in history, and Chrome's 3rd entry (with the correct title) is missing in Firefox.

We must investigate the original reasoning around skipping POST visits and eval if it's worth lifting it. The code is in DocumentLoadListener::RedirectToRealChannel

Comment 3

[Marco Bonardo [:mak]]

In Bug 556400 POST pages were excluded for the reason you can't really re-navigate to a POST page without re-submitting the POST data. History doesn't store POST data along with pages. Thus the assumption was that having these urls in history may be confusing for users revisiting them, especially from the Address Bar. Most browsers excluded POST pages at the time so it was aligning with the status quo.

In this specific case the POST data doesn't matter.
Chrome just decided to store POST pages, ignoring the possible re-navigation issues.
If the POST page is non idempotent, it will likely handle it nicely or with a 4xx error, something history and the browser can already handle.
After all, even a GET request with a single use token/session will be potentially not re-visitable, even not being a POST request, and those pages are not excluded.

If we decide to let POST targets reach global history, we could add a flag for it, and let each history implementation decide how/if to handle it. For example we may set their frecency to 0 to exclude them from the Address Bar, and continue excluding them on Mobile until they decide how to handle. Also in the original bug it was suggested by Boris to leave the decision to the global history implementation, at the time.

Comment 4

[Marco Bonardo [:mak]]

Attachment: Bug 2052799 - Move handling of POST visits from network to IHistory. Desktop Places now stores them.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/a6ef1e0a5f73
https://hg.mozilla.org/integration/autoland/rev/a345255f12d0
Move handling of POST visits from network to IHistory. Desktop Places now stores them. r=geckoview-reviewers,places-reviewers,tcampbell,Standard8

Comment 6

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/a345255f12d0