Closed
Bug 418146
Opened 16 years ago
Closed 16 years ago
Not taken directly to add-on details page for experimental add-ons when logging in via category listings
Categories
(addons.mozilla.org Graveyard :: Public Pages, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
3.2
People
(Reporter: stephend, Assigned: wenzel)
References
()
Details
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
Reporter | ||
Updated•16 years ago
|
Summary: Not taken directly to privacy policy/XPI install for experimental add-ons when logging in via category listings → Not taken directly to add-on details page for experimental add-ons when logging in via category listings
Assignee | ||
Comment 1•16 years ago
|
||
Ah, okay I didn't know this was the intended behavior, but it makes sense. I'll check on that.
Assignee: nobody → fwenzel
Target Milestone: --- → 3.2
Reporter | ||
Comment 2•16 years ago
|
||
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•16 years ago
|
||
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.
Reporter | ||
Comment 4•16 years ago
|
||
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!)
Assignee | ||
Comment 5•16 years ago
|
||
Okay -- but where does that login button take you then after you've successfully submitted the login form?
Comment 6•16 years ago
|
||
After the login screen, it should take you to the addon details page for that addon.
Assignee | ||
Comment 7•16 years ago
|
||
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.
Assignee | ||
Comment 8•16 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 9•16 years ago
|
||
Why can't I see this fixed on preview? Is the auto-SVN-up not running, again?
Reporter | ||
Comment 10•16 years ago
|
||
(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
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
•