1421431 - Problems in Firefox with an encoded backslash in url.

Status: UNCONFIRMED

(Firefox :: Address Bar, defect, P5)

Description

[Maarten Bruins]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36

Steps to reproduce:

My Firefox version is: 57.0 (64-bit) up to date

I reduced the bug to this example. On my server is made a directory "test" with the following htaccess file:

    <IfModule mod_rewrite.c>
        RewriteEngine On
        RewriteBase /
        RewriteRule ^a\\b$ http://www.example.com/first-match [L]
        RewriteRule ^a/b$ http://www.example.com/second-match [L]
    </IfModule>

%5c = backslash encoded

The first time i typed: http://www.my-domain.com/test/a%5cb in the addressbar, Firefox sent me to: http://www.example.com/first-match
The second time i typed: http://www.my-domain.com/test/a%5cb in the addressbar, Firefox sent me to: http://www.example.com/second-match

Firefox needs to send me in both cases to http://www.example.com/first-match like for example Google Chrome is doing.


Actual results:

Firefox sent me to the wrong url.


Expected results:

Firefox should send me to the right url.

Comment 1

[Michal Novotny [:michal]]

(In reply to Maarten Bruins from comment #0)
> The second time i typed: http://www.my-domain.com/test/a%5cb in the
> addressbar, Firefox sent me to: http://www.example.com/second-match

The problem is that firefox changes the URL in the URL bar to http://www.my-domain.com/test/a\b and in this case we correctly replace the the backslash with a slash (implemented in bug 652186), i.e. the address bar must not change %5c to a backslash when typing or pasting URL.

Comment 2

[Drew Willcoxon :adw]

I bet this has to do with the heuristic visit result that UnifiedComplete generates.  The first time the URL isn't in history but the second time it is, or something like that.

Comment 3

[:Gijs (he/him)]

Dupe of bug 1026938?

Comment 4

[Marco Bonardo [:mak]]

(In reply to :Gijs (he/him) from comment #3)
> Dupe of bug 1026938?

It looks quite similar, though that bug seems to only care about the query string.
In the end it all boils down to bug 1163959 and losslessDecodeURI.
It's a rabbit hole and it's unclear how much time it would take for someone to really dig into these encoding problems in the Address Bar and addressing all the edge cases (with tests as well). It needs a dedicated person to just spend time on it, or a rearchitecture of how the address bar copes with user input, we want to show a readable url to the user, but we also want to preserve the original url (that is not readable), all while allowing the user to edit it.
We should probably drop some of these requirements to be able to proceed, considering the current market share, it is not good that we handle urls differently from Chrome (since sadly most devs will only test on it), even if we consider our solution better (and probably it is, but still...).

I don't think there's a strict relation with unifiedcomplete, we seem to store the undecoded url in history.
For that, it may be interesting to know what "type" means in comment 0, if the url was actually typed twice from scratch, or just reconfirmed from what was in the urlbar.

Anyway, someone should spend an unknown amount of time on bug 1163959 to figure out a solid solution.

Comment 5

[Florian Keller]

> we want to show a readable url to the user

Please, as a web developer, let me deactivate that notion! It is really aggravating working with a web server who denies any request including "\", when the browser decides to decode "%5C" at any opportunity. I don't need readable URLs, but I need to manually edit URLs without them breaking suddenly.

Comment 6

[-]

[redacted - mhoye]