Bug 1637408 Comment 1 Edit History

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

according to the STR, we are in the pageproxystate != "valid" case, and the code is doing what it's supposed to do, by inspection.
We used _resultForCurrentValue before that of course had information about the origin of the value, but that method was not reliable when another page started loading because it was overridden already by _loadURL.
additionally the user could pick a url result, modify the text and then copy it, expecting a url, since it started from a url.
If the view is open, we could rely on the heuristic result.
When the view is closed, we don't know, we could pass the string to URIFixup, and if the only difference is the protocol use the fixup url.
I just noticed that in Chrome pressing ESC doesn't just close the view, but also reverts input to the current page, that way they don't have to deal with this problem!
according to the STR, we are in the pageproxystate != "valid" case, and the code is doing what it's supposed to do, by inspection.
We used _resultForCurrentValue before that of course had information about the origin of the value, but that method was not reliable when another page started loading because it was overridden already by _loadURL.
additionally the user could pick a url result, modify the text and then copy it, expecting a url, since it started from a url.
If the view is open, we could rely on the heuristic result.
When the view is closed, we don't know, we could try to still use _resultForCurrentValue, or pass the string to URIFixup, and if the only difference is the protocol use the fixup url.
I just noticed that in Chrome pressing ESC doesn't just close the view, but also reverts input to the current page, that way they don't have to deal with this problem!

Back to Bug 1637408 Comment 1