As I explained in #search the problem here is trimming, if the result points to "http://unknown.probably.invalid/something", and we trim it, we end up with "unknown.probably.invalid/something". Now if the user just confirms the entry we "pick" the result and everything is fine. If instead the user closes the results pane (esc) or edits the value, then because the domain looks invalid, we consider it a search string. But the original result was a url, so we should not change its nature. I found 2 possible paths to fix this: 1. we stop trimming the value when it's set by a result, so basically moving through the results with the keyboard always sets an untrimmed value. I don't see many downsides to this, the input field may look a bit uglier when selecting entries, but either the user will visit it or they want to edit a url, in both cases doesn't seem that trimming gives much value. 2. when a result is selected and gets trimmed, we pass the value to URIFixup and if its nature changes, we untrim it. Now of course option 2 is more expensive, on every trimmed value selection we'd have to go through URIFixup, that may not seem much now considered only http is trimmed, but in a future world where most things are https, it would be a price we may not want to pay. I have a patch implementing 1 for now, and I'd like feedback about the approach, or alternative ideas.
Bug 1635033 Comment 5 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
As I explained in #search the problem here is trimming, if the result points to "http://unknown.probably.invalid/something", and we trim it, we end up with "unknown.probably.invalid/something". Now if the user just confirms the entry we "pick" the result and everything is fine. If instead the user closes the results pane (esc) or edits the value, then because the domain looks invalid, we consider it a search string. But the original result was a url, so we should not change its nature. I found 2 possible paths to fix this: 1. we stop trimming the value when it's set by a result, so basically moving through the results with the keyboard always sets an untrimmed value. I don't see many downsides to this, the input field may look a bit uglier when selecting entries, but either the user will visit it or they want to edit a url, in both cases doesn't seem that trimming gives much value. 2. when a result is selected and gets trimmed, we pass the value to URIFixup and if its nature changes, we untrim it. Now of course option 2 is more expensive, on every trimmed value selection we'd have to go through URIFixup, that may not seem much now considered only http is trimmed, but in a future world where most things are https, it would be a price we may not want to pay. I have a patch implementing 1 for now, and I'd like feedback about picking that approach, or alternative ideas.
As I explained in #search the problem here is trimming, if the result points to "http://unknown.probably.invalid/something", and we trim it, we end up with "unknown.probably.invalid/something". Now if the user just confirms the entry we "pick" the result and everything is fine. If instead the user closes the results pane (esc) or edits the value, then because the domain looks invalid, we consider it a search string. But the original result was a url, so we should not change its nature. I found 2 possible paths to fix this: 1. we stop trimming the value when it's set by a result, so basically moving through the results with the keyboard always sets an untrimmed value. I don't see many downsides to this, the input field may look a bit uglier when selecting entries, but either the user will visit it or they want to edit a url, in both cases doesn't seem that trimming gives much value. 2. when a result is selected and gets trimmed, we pass the value to URIFixup and if its nature changes, we untrim it. Now of course option 2 is more expensive, on every trimmed value selection we'd have to go through URIFixup, that may not seem much now considered only http is trimmed, but in a future world where most things are https and we trim https, it would be a price we may not want to pay. I have a patch implementing 1 for now, and I'd like feedback about picking that approach, or alternative ideas.