Closed Bug 1149548 Opened 6 years ago Closed 6 years ago
keyword search from the location bar is now case sensitive - previously wasn't
STR: 1. create a bookmark like: Name: Bugzilla Keyword Search Location: https://bugzilla.mozilla.org/show_bug.cgi?id=%s Keyword: bug 2. Type and enter: bug 1145063 3. Actual results: https://bugzilla.mozilla.org/show_bug.cgi?id=1145063 4. Type and enter: Bug 1145063 5. Actual results: https://www.google.com/search?q=Bug+1145063&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:unofficial&client=seamonkey-a
maybe a regression from bug 1125117? It seems to be working for me though...
Can't reproduce this either. Philip, can you check again?
I should mention that I build and test SeaMonkey trunk almost every day. Is there anything in the front end code I need to change in SeaMonkey?
Aha, so that's a SeaMonkey bug. Not aware of any frontend changes but Marco should know.
You should check your version of getShortcutOrURIAndPostData in browser probably (or whatever function you use to figure if words represent keywords or not)... I think all of the other changes are in the backend
(In reply to Marco Bonardo [::mak] from comment #5) > You should check your version of getShortcutOrURIAndPostData in browser > probably (or whatever function you use to figure if words represent keywords > or not)... I think all of the other changes are in the backend
Depends on: 1148191
actually, there's a bug here http://mxr.mozilla.org/mozilla-central/source/toolkit/components/places/PlacesUtils.jsm#948 The aKeyword should be lowercased in stmt.params.keyword = aKeyword; This should fix your problem also if you don't immediately port the browser changes.
Points: --- → 1
(In reply to Marco Bonardo [::mak] from comment #7) > actually, there's a bug here > http://mxr.mozilla.org/mozilla-central/source/toolkit/components/places/ > PlacesUtils.jsm#948 > > The aKeyword should be lowercased in stmt.params.keyword = aKeyword; Thanks! I came to the same conclusion after staring at the code for a while. > This should fix your problem also if you don't immediately port the browser > changes. This is on our radar but I don't know when we'll port the browser changes. Also [addon-compat]
Assignee: nobody → philip.chee
Status: NEW → ASSIGNED
Attachment #8587918 - Flags: review?(mak77)
Whiteboard: [good first bug][lang=js]
Version: unspecified → Trunk
(In reply to Philip Chee from comment #8) > This is on our radar but I don't know when we'll port the browser changes. > Also [addon-compat] So far I made all new APIs be able to work along the old ones... clearly we can't keep the old ones forever, but surely we'll Deprecate.warning at least a couple versions before any removal.
note this fix is worth uplifting to Aurora.
Try server results: https://treeherder.mozilla.org/#/jobs?repo=try&revision=86029fe3ce2a
https://hg.mozilla.org/integration/fx-team/rev/3f9f9202ea64 Should we have a test for this?
Comment on attachment 8587918 [details] [diff] [review] Patch fix getURLAndPostDataForKeyword Approval Request Comment [Feature/regressing bug #]: Bug 1100294 [User impact if declined]: [addon-compat] The keyword used in urlbar searches is now unintentionally case sensitive for SeaMonkey and addons that use the old API. [Describe test coverage new/current, TreeHerder]: current try server results are Green: https://treeherder.mozilla.org/#/jobs?repo=try&revision=b7e8d67b2e37 [Risks and why]: low risk regression fix. [String/UUID change made/needed]: none.
Attachment #8587918 - Flags: approval-mozilla-aurora?
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #12) > https://hg.mozilla.org/integration/fx-team/rev/3f9f9202ea64 > > Should we have a test for this? we could but this code is deprecated.
Comment on attachment 8587918 [details] [diff] [review] Patch fix getURLAndPostDataForKeyword Looks low risk, fixes a regression. Approving for uplift to aurora.
Attachment #8587918 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.