418146 - Not taken directly to add-on details page for experimental add-ons when logging in via category listings

Status: VERIFIED FIXED

(addons.mozilla.org Graveyard :: Public Pages, defect)

Description

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

Summary: Not taken directly to privacy policy/XPI install for experimental add-ons when logging in via category listings

When I verified bug 414896, I apparently neglected to check that logging in from the category-browse view takes you directly to the add-on's details page for experimental add-ons (as it correctly does if you're already in that view).

In fact, it doesn't work.

Steps to Reproduce:

1. In the logged-out view, load https://preview.addons.mozilla.org/en-US/firefox/browse/type:1/cat:5?show=10&exp=on&sort=name
2. Click on any of the experimental "Add to Firefox" buttons
3. Log in

Expected Results:

You should either be taken to its Policy page or directly trigger its XPI

Actual Results:

Instead, you're taken back to the category listing page (but are logged in), because the parameter passed to loginto? is:

https://preview.addons.mozilla.org/en-US/firefox/users/login?to=en-US%2Ffirefox%2Fbrowse%2Ftype%3A1%2Fcat%3A5%3Fshow%3D10%26exp%3Don%26sort%3Dname

As an example, I'd expect that clicking on "4Shared.com Hack" would kick off a URL such as:

https://preview.addons.mozilla.org/en-US/firefox/users/login?to=addon%2F4923&m=1

Comment 1

[Fred Wenzel [:wenzel]]

Ah, okay I didn't know this was the intended behavior, but it makes sense. I'll check on that.

Comment 2

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

Oh, well it might not be the spec'd behavior, but it did seem to make sense to me, based on the behavior we have on other pages; maybe we can bring it up in the meeting and make a quick decision.

Comment 3

[Madhava Enros [:madhava]]

I think that the original behavior that I'd had in mind was that the "Add to Firefox" buttons be disabled until you were logged in:

http://wiki.mozilla.org/Update:Remora_UI_Review/Mockups/Home_Page/2007-09-12_revisions/#Full_listings_page

but I think that I didn't follow up on this well enough, because by this point:

http://mozilla.focalcurve.com/searchresults.html

the button is disabled in look, but not feel -- ie, it's greyed out, but still clickable and even has a hover effect.

We can either make the button really disabled, which gets rid of this state altogether, or, if people think it's valuable to let people click through to the login screen, we can have it behave the way stephen describes above.

Comment 4

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

We decided in the meeting, I think, to make the buttons really disabled in this view, and just force a straight login via the link at the top of the page.

(I hope I got that right!)

Comment 5

[Fred Wenzel [:wenzel]]

Okay -- but where does that login button take you then after you've successfully submitted the login form?

Comment 6

[Basil Hashem [:baz]]

After the login screen, it should take you to the addon details page for that addon.

Comment 7

[Fred Wenzel [:wenzel]]

Ouch; I just found out that removing the link will require completely changing the CSS Craig made for all install buttons -- I wasn't aware of that in the meeting otherwise I'd have objected. Is it fine if we just change the link target then and keep the experimental install button pointing to the login page?

If not (and in particular if we fear it'll be bad for UX), I'll go ahead and rip the CSS styles apart, but I'd like to avoid that if it's not a big deal.

Comment 8

[Fred Wenzel [:wenzel]]

SVN r10627. The buttons and "log in" link now take you to the add-ons details page after you logged in successfully. I refrained from removing the link off the experimental install button altogether for now, because Craig's CSS heavily relies on the different install buttons behaving similarly.

Closing for now, but if the link turns out to harm user experience, please reopen.

Comment 9

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

Why can't I see this fixed on preview?  Is the auto-SVN-up not running, again?

Comment 10

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

(In reply to comment #9)
> Why can't I see this fixed on preview?  Is the auto-SVN-up not running, again?

That was bug 420686; now that it's been fixed, I'm able to verify this bug, which works wonderfully.

Verified FIXED:

https://preview.addons.mozilla.org/en-US/firefox/browse/type:1/cat:5?show=10&exp=on&sort=name