Leading space not stripped when using keyword search from URL bar

NEW
Unassigned

Status

()

defect
P3
normal
3 years ago
3 years ago

People

(Reporter: mozdev2, Unassigned)

Tracking

48 Branch
x86_64
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fxsearch])

Reporter

Description

3 years ago
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0
Build ID: 20160728203720

Steps to reproduce:

I have a keyword set up for my wikipedia search engine so I can enter "w sometopic" to search wikipedia for "sometopic". Works great.

If I accidentally enter " w sometopic" (note leading space) it gives me a "The address isn't valid" page. It should strip leading spaces, IMO.


Actual results:

"The address isn't valid".


Expected results:

Expected: it should have gone to the wikipedia search results for "sometopic".
Reporter

Updated

3 years ago
OS: Unspecified → Linux
Hardware: Unspecified → x86_64

Comment 1

3 years ago
WFM on FF48 as well as latest nightly. Have you tried it in safe mode?
Flags: needinfo?(mozdev)
Reporter

Comment 2

3 years ago
Thanks for checking! And yes -- same in safe mode. But: I have discovered that one must set the pref "keyword.enabled" to false to see this behavior.

I do this because I do not want random (accidental) strings in the URL bar to be searched on. Oddly, with this pref set to false, it still searches when explicit keywords are used, e.g. "w sometopic", which is great because it's my desired behavior, but the pref is apparently a misnomer.

Note that if keyword.enabled is set to "true", " w sometopic" still fails in that it uses the default search engine instead of wikipedia.
Flags: needinfo?(mozdev)

Updated

3 years ago
Component: Untriaged → Location Bar
provided we should check it's not going to break other stuff, it seems to make sense to trim leading spaces.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
Whiteboard: [fxsearch]
You need to log in before you can comment on or make changes to this bug.