Closed
Bug 426085
Opened 16 years ago
Closed 16 years ago
"Get more search engines..." link in browser goes to slightly confusing page
Categories
(addons.mozilla.org Graveyard :: Search Plugins, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
3.2.1
People
(Reporter: wgianopoulos, Assigned: oremj)
References
()
Details
(Keywords: regression)
Attachments
(1 file)
876 bytes,
patch
|
wenzel
:
review+
|
Details | Diff | Splinter Review |
The recent update to AMO has broken the "Get more search engines..." link. This needs to be fixed in AMO and NOT in the browser as this has broken Firefox 2 as well.
Reporter | ||
Updated•16 years ago
|
Summary: Updated AMO site breaks "Get more search engines..." link in borwser → Updated AMO site breaks "Get more search engines..." link in browser
Updated•16 years ago
|
Version: unspecified → 3.2
When users use the "get more search engines" link under "manage search engines" on the search bar drop down they get taken to: https://addons.mozilla.org/en-US/firefox/browse/type:4 On the new AMO site this leaves the user in a really confusing place where it is not immediately obvious where to go to find search engines to add to the search bar. In reality the "get more search engines" links should land on: https://addons.mozilla.org/en-US/firefox/browse/type:4/cat:all?sort=name This would bring the user directly to the list of search engines that can be added to the search bar, rather than presenting lists of recommended extensions that manipulate search results presented by search engines.
Keywords: regression
Comment 2•16 years ago
|
||
Updating summary to reflect the issue, as if the link were actually broken this would be a blocker. I think the point of using the Search Tools landing page was so users can choose the category of search engine they're looking for rather than just seeing a big multi-page listing (that will get much larger in the future).
Summary: Updated AMO site breaks "Get more search engines..." link in browser → "Get more search engines..." link in browser goes to slightly confusing page
I'd recommend either removing the word "slightly" or replacing it with "very". The page is much more than "slightly" confusing. If you are correct about the purpose of the page to be able to choose from search engine categories, then extensions need to be excluded from the landing page as they are contributing to much of the confusion. The landing page for the "get more search engines..." link should ONLY be for search engines that can be added to the search bar, it should not include extensions that modify search behaviors or search results pages.
Have to scroll a complete page just to see the search categories. Not very user friendly or intuitive.
Reporter | ||
Comment 5•16 years ago
|
||
Ah, so this is not quite as screwed up as I thought. I nver scrolled down that far and really doubt the typical user clicking on the get more search engines link would either. Also the searchbar at the top is set to search for search tools, which includes search related extensions in addition to search engines. One would expect it to be trying to find search engines only. I would think a page that has something about search engines in the center, a searchbar to search for search engines at the top and an open Categories menu on the left that has the list of search engine categories that is in the box at the lower right of the currently linked page.
Comment 6•16 years ago
|
||
We should point to this page instead: https://addons.mozilla.org/en-US/firefox/browse/type:4/cat:all?sort=name
Comment 7•16 years ago
|
||
(In reply to comment #6) > We should point to this page instead: > https://addons.mozilla.org/en-US/firefox/browse/type:4/cat:all?sort=name What about Firefox 2?
Reporter | ||
Comment 8•16 years ago
|
||
(In reply to comment #7) > (In reply to comment #6) > > We should point to this page instead: > > https://addons.mozilla.org/en-US/firefox/browse/type:4/cat:all?sort=name > > What about Firefox 2? > I did mention that int he original comment. Changing the current trunk to point to a different location can not fix the problem.
Updated•16 years ago
|
Target Milestone: --- → 3.2.1
Comment 9•16 years ago
|
||
oremj, could you edit mozilla.com redirect to point here? It's this URL coming from the client: https://en-us.add-ons.mozilla.com/en-US/firefox/3.0b5pre/search-engines/
Assignee: nobody → rdoherty
Updated•16 years ago
|
Assignee: rdoherty → oremj
Comment 10•16 years ago
|
||
You sure that's not on our end in this controller? http://svn.mozilla.org/addons/trunk/site/app/controllers/legacy_url_controller.php
Comment 11•16 years ago
|
||
clouserw is correct. :)
Comment 12•16 years ago
|
||
reed: for the search engines bug, maybe we should lead them to the "sort by popularity" list rather than name? That's at least where the "get Bookmark add-ons" link in Firefox points to in its category.
Comment 13•16 years ago
|
||
(In reply to comment #12) > reed: for the search engines bug, maybe we should lead them to the "sort by > popularity" list rather than name? Sounds good. I can fix that on commit, or I can attach a new patch, if you want.
Comment 14•16 years ago
|
||
Comment on attachment 312841 [details] [diff] [review] patch - v1 (checked in) That wfm. And actually, I think it is more intuitive to get the search engines list by name (unlike regular add-ons where the name is largely arbitrary). So you can keep the link that way.
Attachment #312841 -
Flags: review?(morgamic) → review+
Comment 15•16 years ago
|
||
Sending site/app/controllers/legacy_url_controller.php Transmitting file data . Committed r11875.
Comment 17•16 years ago
|
||
If my bug, Bug 428246, is a dupe, and this was fixed a week ago, then why am I still getting the wrong page?
Comment 18•16 years ago
|
||
push-needed: "For website/webtool (but usually just AMO) bugs that have been checked in but not yet pushed to production servers."
Comment 19•16 years ago
|
||
seems like resolving a bug which hasn't actually been fixed yet will increase dupes and lead to reporter confusion more often than not (like the one I filed. I searched first, but searched open bugs since this was still a problem.) wouldn't a dependency on the "push the changes live" bug be a better mechanism than a keyword?
Comment 20•16 years ago
|
||
I don't know how this is usually dealt with, but I'm reopening this bug for now.
Status: RESOLVED → REOPENED
Flags: blocking1.8.1.15?
Flags: blocking-firefox3?
Resolution: FIXED → ---
Updated•16 years ago
|
Attachment #312841 -
Attachment description: patch - v1 → patch - v1 (checked in)
Comment 21•16 years ago
|
||
This bug was completed the correct way. AMO resolves bugs as patches are landed in Subversion and adds the push-needed keyword to the bugs for tracking eventual push to production.
Status: REOPENED → RESOLVED
Closed: 16 years ago → 16 years ago
Flags: blocking1.8.1.15?
Flags: blocking-firefox3?
Resolution: --- → FIXED
Comment 22•16 years ago
|
||
(In reply to comment #21) > eventual push to production. When does this happen?
Comment 23•16 years ago
|
||
and are the keywords then removed? keyword changes aren't queryable so that kinda sucks.
Comment 24•16 years ago
|
||
and where's the bug I can track to see when the push is scheduled for or completed?
Comment 25•16 years ago
|
||
(In reply to comment #23) > and are the keywords then removed? Yep (In reply to comment #24) > and where's the bug I can track to see when the push is scheduled for or > completed? Hasn't been filed yet
Comment 26•16 years ago
|
||
This bug is targeted for 3.2.1, so it will be pushed live when 3.2.1 is pushed live, currently aimed for next Tuesday or Thursday. The update bug won't be filed until we are ready for the push.
Comment 27•16 years ago
|
||
OK. thanks for the info guys. I think that resolving a bug without giving the people concerned with the bug specific information about when it will actually be fixed or a mechanism to follow that themselves (something like a "push scheduled for dd/mm/yy" or a link to the "push these files live" bug) is a bad practice. And as I said above, keywords are pretty awful in terms of queryability of changes so that's not a very useful approach for people following the bug (and not using bugmail.) It's your world and not mine, so take these suggestions or leave them.
Tested on http://preview.addons.mozilla.org/en-US/firefox/search-engines/ with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.12) Gecko/20070508 Firefox/1.5.0.12 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.13) Gecko/2008031114 Firefox/2.0.0.13 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5 -and- Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008041004 Minefield/3.0pre Verified FIXED
Status: RESOLVED → VERIFIED
Comment 29•16 years ago
|
||
I think this regressed in AMO 3.4.1, so I'm re-opening and targeting for AMO 3.4.2. Stephend, can you verify that we've regressed please?
(In reply to comment #29) > I think this regressed in AMO 3.4.1, so I'm re-opening and targeting for AMO > 3.4.2. Stephend, can you verify that we've regressed please? As discussed on IRC, I'm being taken to https://addons.mozilla.org/en-US/firefox/browse/type:4 instead of https://addons.mozilla.org/en-US/firefox/browse/type:4/cat:all?sort=name, using Firefox 2.0.0.14 on Windows.
Comment 31•16 years ago
|
||
Fwiw, the redirect for the URL in comment 28 still redirects to the list view correctly (on preview and in production). Is this a Firefox bug, then? What URL does Fx currently use, has it changed?
Comment 32•16 years ago
|
||
comment 28's URL doesn't work for me in production - only preview. It's probably a rewrite IT has setup that's in production but not on preview.
The in-client URL for branch builds is: https://%LOCALE%.add-ons.mozilla.com/%LOCALE%/firefox/%VERSION%/search-engines/
Comment 34•16 years ago
|
||
(In reply to comment #32) > comment 28's URL doesn't work for me in production - only preview. It's > probably a rewrite IT has setup that's in production but not on preview. That URL is handled by the legacy URL controller in AMO, IIRC. The URL: http://addons.mozilla.org/en-US/firefox/search-engines/ Takes me to... https://addons.mozilla.org/en-US/firefox/browse/type:4/cat:all?sort=name However, https://en-US.add-ons.mozilla.com/en-US/firefox/3.0b5/search-engines/ (derived from stephend's pattern in comment 33) takes me to: https://addons.mozilla.org/en-US/firefox/browse/type:4 Which would indeed probably make this an IT redirect issue. CCing oremj: Jeremy, could you please take a look at the redirect that's responsible for the URL in comment 33 (or comment 9)?
Assignee | ||
Comment 35•16 years ago
|
||
These are the current rewrites: RewriteRule ^/(cs|da|de|en-US|el|es-ES|eu|fi|fr|it|ja|ko|mn|nl|pl|ro|ru|sk|sq|uk)/(.+?)/(\d.+?)/search-engines/?$ https://addons.mozilla.org/$1/firefox/browse/type:4 [R,L] RewriteRule ^/(\w{2,3}(-\w{2}(-mac)?)?)/(.+?)/(.+?)/search-engines/?$ https://addons.mozilla.org/en-US/firefox/browse/type:4 [R,L]
Comment 36•16 years ago
|
||
Oremj: Thanks. Would you please append "/cat:all?sort=name" to both of these URLs? You can then close this bug.
Assignee: reed → oremj
Status: REOPENED → NEW
Assignee | ||
Comment 37•16 years ago
|
||
Fixed.
Status: NEW → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → FIXED
OK; verified this for real now (tm) using Firefox 3 rc1, 2.0.0.14 and 1.5 on Windows XP SP3; they all took me to https://addons.mozilla.org/en-US/firefox/browse/type:4/cat:all?sort=name.
Status: RESOLVED → VERIFIED
Updated•8 years ago
|
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•