Bug 1773298 Comment 22 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Although the verification comes a bit late,here's the results, as follows:

1. There are differences in behaviour betwen the **latest 104+beta 103** and the **ESR 102.0.1** see [video]()
- latest 104 + beta 103 an input like ABOUT:LOGINS or about:LOGINS will always force about:logins navigation
- ESR 102.0.1 an input like ABOUT:LOGINS will force toLOWER for about, resulting in about:LOGINS navigation, which is broken
2. Edit string with UPPER will allow the access to the edited address: (already mentioned in comment 9)
- about:logins edited into about:logINs will navigate to about:logINs which doesn't work (latest 104, beta 103 and ESR 102.0.1)
3. Copy/paste string will result into navigation to an invalid string copy ABOUT:LOGINS and address bar will navigate to about:LOGINS (latest 104, beta 103 and ESR 102.0.1)

James, for point 1, I tried with mozregression to find fix to see if something changed betwen 103 and 102 but mozregression did only point to this patch. Any idea why ESR behaves differently than 103b and 104 Nightly; was the patch applied incomplete?

Taking this bug verification as purely toLower for about protocol we might consider it as verified, but the above scenarios would still affect the users who would navigate to a broken page using one of the 2nd or 3rd scenario (e.g. about:HOME, about:hoMe or about:LOGIN) and although this might seem like an edge case, I think this would be rather the main usage case, in which you type about:logns and then the I that's missing would be a caps I. 
I'm also a bit confused why some of the protocol pages from about:about long list seem unaffected by the 2-3 scenarios, while others seem to be doing just fine, no mater what capitalization are in.

Finally, just my two cents on the approach here. While the toLower for about protocol makes sense, IMO, it's editing user input, which I don't see as a best practice: I would've liked more an approach in which the user input in in address bar remains unchanged, which backend would toLOWER the entire string loading the target right about:page.
Although the verification comes a bit late,here's the results, as follows:

1. There are differences in behaviour betwen the **latest 104+beta 103** and the **ESR 102.0.1** see [video](https://bugzilla.mozilla.org/attachment.cgi?id=9286069)
- latest 104 + beta 103 an input like ABOUT:LOGINS or about:LOGINS will always force about:logins navigation
- ESR 102.0.1 an input like ABOUT:LOGINS will force toLOWER for about, resulting in about:LOGINS navigation, which is broken
2. Edit string with UPPER will allow the access to the edited address: (already mentioned in comment 9)
- about:logins edited into about:logINs will navigate to about:logINs which doesn't work (latest 104, beta 103 and ESR 102.0.1)
3. Copy/paste string will result into navigation to an invalid string copy ABOUT:LOGINS and address bar will navigate to about:LOGINS (latest 104, beta 103 and ESR 102.0.1)

James, for point 1, I tried with mozregression to find fix to see if something changed betwen 103 and 102 but mozregression did only point to this patch. Any idea why ESR behaves differently than 103b and 104 Nightly; was the patch applied incomplete?

Taking this bug verification as purely toLower for about protocol we might consider it as verified, but the above scenarios would still affect the users who would navigate to a broken page using one of the 2nd or 3rd scenario (e.g. about:HOME, about:hoMe or about:LOGIN) and although this might seem like an edge case, I think this would be rather the main usage case, in which you type about:logns and then the I that's missing would be a caps I. 
I'm also a bit confused why some of the protocol pages from about:about long list seem unaffected by the 2-3 scenarios, while others seem to be doing just fine, no mater what capitalization are in.

Finally, just my two cents on the approach here. While the toLower for about protocol makes sense, IMO, it's editing user input, which I don't see as a best practice: I would've liked more an approach in which the user input in in address bar remains unchanged, which backend would toLOWER the entire string loading the target right about:page.
Although the verification comes a bit late,here's the results, as follows:

1. There are differences in behaviour betwen the **latest 104+beta 103** and the **ESR 102.0.1** see [video](https://bugzilla.mozilla.org/attachment.cgi?id=9286069)
- latest 104 + beta 103 an input like ABOUT:LOGINS or about:LOGINS will always force about:logins navigation
- ESR 102.0.1 an input like ABOUT:LOGINS will force toLOWER for about, resulting in about:LOGINS navigation, which is broken
2. Edit string with UPPER will allow the access to the edited address: (already mentioned in comment 9)
- about:logins edited into about:logINs will navigate to about:logINs which doesn't work (latest 104, beta 103 and ESR 102.0.1)
3. Copy/paste string will result into navigation to an invalid string copy ABOUT:LOGINS and address bar will navigate to about:LOGINS (latest 104, beta 103 and ESR 102.0.1)

James, for point 1, I tried with mozregression to find fix to see if something changed betwen 103 and 102 but mozregression did only point to this patch. Any idea why ESR behaves differently than 103b and 104 Nightly; was the patch applied incomplete?

Taking this bug verification as purely toLower for about protocol we might consider it as verified, but the above scenarios would still affect the users who would navigate to a broken page using one of the 2nd or 3rd scenario (e.g. about:HOME, about:hoMe or about:LOGIN) and although this might seem like an edge case, I think this would be rather the main usage case, in which you type about:logns and then the I that's missing would be a caps I. 
I'm also a bit confused why some of the protocol pages from about:about long list seem affected by the 2-3 scenarios, while others seem to be doing just fine, no mater what capitalization are in.

Finally, just my two cents on the approach here. While the toLower for about protocol makes sense, IMO, it's editing user input, which I don't see as a best practice: I would've liked more an approach in which the user input in in address bar remains unchanged, which backend would toLOWER the entire string loading the target right about:page.
Although the verification comes a bit late,here's the results, as follows:

1. There are differences in behaviour betwen the **latest 104+beta 103** and the **ESR 102.0.1** see [video](https://bugzilla.mozilla.org/attachment.cgi?id=9286069)
- latest 104 + beta 103 an input like ABOUT:LOGINS or about:LOGINS will always force about:logins navigation
- ESR 102.0.1 an input like ABOUT:LOGINS will force toLOWER for about, resulting in about:LOGINS navigation, which is broken
2. Edit string with UPPER will allow the access to the edited address: (already mentioned in comment 9)
- about:logins edited into about:logINs will navigate to about:logINs which doesn't work (latest 104, beta 103 and ESR 102.0.1)
3. Copy/paste string will result into navigation to an invalid string copy ABOUT:LOGINS and address bar will navigate to about:LOGINS (latest 104, beta 103 and ESR 102.0.1)

James, for point 1, I tried with mozregression to find fix to see if something changed betwen 103 and 102 but mozregression did only point to this patch. Any idea why ESR behaves differently than 103b and 104 Nightly; was the patch applied incomplete?

Taking this bug verification as purely toLower for about protocol we might consider it as verified, but the above scenarios would still affect the users who would navigate to a broken page using one of the 2nd or 3rd scenario (e.g. about:HOME, about:hoMe or about:LOGIN) and although this might seem like an edge case, I think this would be rather the main usage case, in which you type about:logns and then the I that's missing would be a caps I. 
I'm also a bit confused why some of the protocol pages from about:about long list seem affected by the 2-3 scenarios, while others seem to be doing just fine, no mater what capitalization are in.

Finally, just my two cents nitpicking on the approach here. While the toLower for about protocol makes sense, IMO, it's editing user input, which I don't see as a best practice: I would've liked more an approach in which the user input in in address bar remains unchanged, while on backend we would toLOWER the entire string loading the target right about:page or something like that.
Although the verification comes a bit late,here's the results, as follows:

1. ~~There are differences in behaviour betwen the **latest 104+beta 103** and the **ESR 102.0.1** see [video]~~(https://bugzilla.mozilla.org/attachment.cgi?id=9286069)
~~- latest 104 + beta 103 an input like ABOUT:LOGINS or about:LOGINS will always force about:logins navigation~~
~~- ESR 102.0.1 an input like ABOUT:LOGINS will force toLOWER for about, resulting in about:LOGINS navigation, which is broken~~
2. Edit string with UPPER will allow the access to the edited address: (already mentioned in comment 9)
- about:logins edited into about:logINs will navigate to about:logINs which doesn't work (latest 104, beta 103 and ESR 102.0.1)
3. Copy/paste string will result into navigation to an invalid string copy ABOUT:LOGINS and address bar will navigate to about:LOGINS (latest 104, beta 103 and ESR 102.0.1)

~~James, for point 1, I tried with mozregression to find fix to see if something changed betwen 103 and 102 but mozregression did only point to this patch. Any idea why ESR behaves differently than 103b and 104 Nightly; was the patch applied incomplete?~~

Taking this bug verification as purely toLower for about protocol we might consider it as verified, but the above scenarios would still affect the users who would navigate to a broken page using one of the 2nd or 3rd scenario (e.g. about:HOME, about:hoMe or about:LOGIN) and although this might seem like an edge case, I think this would be rather the main usage case, in which you type about:logns and then the I that's missing would be a caps I. 
I'm also a bit confused why some of the protocol pages from about:about long list seem affected by the 2-3 scenarios, while others seem to be doing just fine, no mater what capitalization are in.

Finally, just my two cents nitpicking on the approach here. While the toLower for about protocol makes sense, IMO, it's editing user input, which I don't see as a best practice: I would've liked more an approach in which the user input in in address bar remains unchanged, while on backend we would toLOWER the entire string loading the target right about:page or something like that.

Back to Bug 1773298 Comment 22