User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050118 Firefox/1.0+ Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050118 Firefox/1.0+ When using user_pref("keyword.URL", "http://www.google.com/search?q="); pref, and searching a string in URL bar with spaces, all the links on the search result page do not open if tired to open them in new windows or new tabs. they do open in current window/tab Reproducible: Always Steps to Reproduce: 1. start with a clean profile and set the pref user_pref("keyword.URL", "http://www.google.com/search?q="); 2. open firefox and type this in url bar without quotes: "mozilla firefox" - this should result in a google search results page with "keyword:mozilla firefox" in the URL bar. 3. try to open any links on this search result page in a new window or new tab by either using ctrl + click, or middle click or right click + open in new window/tab Actual Results: No new window or tab opens. Expected Results: A new window or tab should open and load the page linked by the URL.
OS: Linux → All
Summary: keyword: search in URL bar with spaces locks up the search results page → keyword: search in URL bar with spaces prevents opening result links in new window or tab, causes urlSecurityCheck failure
Confirm this is fixed in Firefox 1.0.1 released version (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050223 Firefox/1.0.1).
Sammy_c, This bug never existed on the 1.0 branch. It exists on the trunk, where development for 1.1 release is happening. 1.0.1 release of firefox was bugfixes to the 1.0 version which didn't have this bug.
Oops, sorry. For what it's worth the reason it still works in Firefox 1.0.1 is that the keyword search line in the address bar generated by entering search words in the address bar converts spaces between words to "%20", so entering "testing one two three" in the address bar creates a URL of "keyword:testing%20one%20two%20three", which is apparently acceptable to the URL security checker. Something changed in the trunk revisions that stops this translation of spaces to "%20" happening. If you enter "keyword: one two three" directly in the address bar in 1.0.1 it still does the search but the results page has the same problem as in the bug description.
13 years ago
Flags: blocking-aviary1.1? → blocking-aviary1.1-
this seems to have fixed itself now (atleast on linux 20050325), probably as a dependency of some other bug, as i see no checkins here. Can someone please check this on windows/mac ?
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050325 Firefox/1.0+ Testing in latest-trunk on WindowsXP Pro SP1 Build 2600. Following supplied steps for reproduction, I encounted no problems. This is WFM.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.