"Get more search engines..." link in browser goes to slightly confusing page

VERIFIED FIXED in 3.2.1

Status

addons.mozilla.org Graveyard
Search Plugins
--
major
VERIFIED FIXED
10 years ago
2 years ago

People

(Reporter: WG9s, Assigned: oremj)

Tracking

({regression})

3.2.1
regression

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

10 years ago
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

10 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
Version: unspecified → 3.2

Comment 1

10 years ago
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.

Updated

10 years ago
Keywords: regression
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

Comment 3

10 years ago
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.

Comment 4

10 years ago
Have to scroll a complete page just to see the search categories.  Not very user friendly or intuitive.
(Reporter)

Comment 5

10 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

10 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

10 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

10 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.
Target Milestone: --- → 3.2.1
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
Assignee: rdoherty → oremj
You sure that's not on our end in this controller?
http://svn.mozilla.org/addons/trunk/site/app/controllers/legacy_url_controller.php
Created attachment 312841 [details] [diff] [review]
patch - v1 (checked in)

clouserw is correct. :)
Assignee: oremj → reed
Status: NEW → ASSIGNED
Attachment #312841 - Flags: review?(morgamic)
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.
(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 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+
Sending        site/app/controllers/legacy_url_controller.php
Transmitting file data .
Committed r11875.
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Keywords: push-needed
Resolution: --- → FIXED
Duplicate of this bug: 428246
Blocks: 428251

Comment 17

10 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? 
push-needed: "For website/webtool (but usually just AMO) bugs that have been checked in but not yet pushed to production servers."

Comment 19

10 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? 
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

10 years ago
Attachment #312841 - Attachment description: patch - v1 → patch - v1 (checked in)
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
Last Resolved: 10 years ago10 years ago
Flags: blocking1.8.1.15?
Flags: blocking-firefox3?
Resolution: --- → FIXED
(In reply to comment #21)
> eventual push to production.

When does this happen?

Comment 23

10 years ago
and are the keywords then removed? 

keyword changes aren't queryable so that kinda sucks. 

Comment 24

10 years ago
and where's the bug I can track to see when the push is scheduled for or completed?
(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
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

10 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

10 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?
Status: VERIFIED → REOPENED
Keywords: push-needed
Resolution: FIXED → ---
(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.
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 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/
(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

10 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]
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

10 years ago
Fixed.
Status: NEW → RESOLVED
Last Resolved: 10 years ago10 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
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.