570646 - Relative URLs on the Discovery Pane go to services.amo

Status: RESOLVED FIXED

(addons.mozilla.org Graveyard :: Discovery Pane, defect)

Description

[Robert Claypool]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a5pre) Gecko/20100607 Minefield/3.7a5pre ( .NET CLR 3.5.30729; .NET4.0E)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a5pre) Gecko/20100607 Minefield/3.7a5pre ( .NET CLR 3.5.30729; .NET4.0E)

I went to about:addons, clicked on "Browse all add-ons", got the response, "Forbidden You don't have permission to access /en-US/firefox/ on this server." I went then to Report A Broken Website and got the message, "There was an error creating the report, and so no information was sent to mozilla.org" and "Error Details
    url must use a valid URL syntax http://mozilla.com/page

Then I went to Mozilla QA Companion and got the error message, "Application failed during request deserialization..."

Reproducible: Didn't try

Steps to Reproduce:
1. Go to Tools|Add=ons, click on Browse all add-ons
2.Get Forbidden error. Go to Help|Report Broken Web Site. Enter information and click on "Submit Report".
3. Get error messaage, "There was an error creating the report, and so no information was sent to mozilla.org"
4. Click on QA Icon. QA will give the error message, "Application failed during request deserialization..."
Actual Results:  
Three unusable features in Firefox.

Expected Results:  
Feature should work with no errors. The Browse all add-ons link should take me to add ons, Broken website should see about:addons as a valid URL. QA should not have had any error.

Comment 1

[Dave Townsend [:mossop]]

Seems like three separate bugs. "Browse all add-ons" not working right is AMO's problem. The others should probably be filed separately.

Comment 2

[[not reading bugmail]]

the 2 links of "Get Add-ons" lower right pane both start with services.addons.mozilla.org

removing the _services._ from the URLs goes to valid pages.

Comment 3

[[not reading bugmail]]

The second item, trying to report the forbidden page doesn't update the URL, so the when using that feature, it tries to send about:addons as valid URL.  Which might be a wontfix, since about: pages of firefox are not broken websites.

Comment 4

[Jeff Balogh (:jbalogh)]

Since this bug fell into AMO, I'm retargeting it at the AMO error.

Comment 5

[[not reading bugmail]]

Add https://services.addons.mozilla.org/collection/enkei to the list in the middle section.

Comment 6

[Wil Clouser [:clouserw]]

I see some of the links going to SAMO and some going to AMO.  We can fix it up.  dd:

1) go to about:addons
2) click "get add-ons"
3) hover over a few of the links, some go to SAMO which will 403

Comment 7

[[not reading bugmail]]

I wonder if its possible to get this fixed before beta1?

Comment 8

[Dave Dash [:davedash, :dd] (assign all bugs to mbrandt)]

When's beta 1?

5.11.4 is due July 13.

Comment 9

[Wil Clouser [:clouserw]]

(In reply to comment #8)
> When's beta 1?
> 
> 5.11.4 is due July 13.

The summit is messing up our usual push schedule; this bug is scheduled to go live on July 13th.  See https://mail.mozilla.com/home/[e-mail]/AMO%20Schedule.html

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Well, for beta1 we will serve another page:
https://preview.addons.mozilla.org/z/en-US/firefox/discovery/3.7/Linux

So no need to have a rush here.

Comment 11

[Dave Dash [:davedash, :dd] (assign all bugs to mbrandt)]

r? http://github.com/davedash/zamboni/compare/master...discovery-links-570646

Comment 12

[Jeff Balogh (:jbalogh)]

Does <base> work? http://dev.w3.org/html5/markup/base.html

"The base element specifies a document-wide base URL for the purposes of resolving relative URLs, and a document-wide default browsing context name for the purposes of following hyperlinks."

Comment 13

[Wil Clouser [:clouserw]]

(In reply to comment #11)
> r? http://github.com/davedash/zamboni/compare/master...discovery-links-570646

I don't have separate hosts but it seems like that would work.  I agree <base> would be cleaner though - can we use that here?

Comment 14

[Dave Dash [:davedash, :dd] (assign all bugs to mbrandt)]

http://github.com/davedash/zamboni/compare/master...discovery-links-570646-take-2

We can!

Google Chrome likes it, I don't see why Firefox wouldn't either :)

Comment 15

[Dave Dash [:davedash, :dd] (assign all bugs to mbrandt)]

http://github.com/jbalogh/zamboni/commits/9f754c9

Comment 16

[Stephen Donner [:stephend] Not actively reading bugmail]

How do I test this on preview?

Do I just change |extensions.webservice.discoverURL| and set it to https://preview.addons.mozilla.org/%LOCALE%/%APP%/discovery/%VERSION%/%OS% ?

Comment 17

[Wil Clouser [:clouserw]]

@stephend: This isn't easily testable since PAMO doesn't have multiple hostnames pointing at it.

@davedash: I don't think your fix works anymore.  SAMO has it's own settings.py so your fix will just hardcode all the links to SAMO.  We want them hardcoded to AMO.

Comment 18

[Dave Dash [:davedash, :dd] (assign all bugs to mbrandt)]

SITE_URL should always be whatever the actual AMO site is, not SAMO.

Can I see settings_local.py for SAMO?

Comment 19

[Stephen Donner [:stephend] Not actively reading bugmail]

Reopening so we don't drop comment 17 and comment 18 on the floor.