Search should default to searching for available add-ons

VERIFIED FIXED in mozilla2.0b10

Status

()

Toolkit
Add-ons Manager
VERIFIED FIXED
7 years ago
6 years ago

People

(Reporter: mossop, Assigned: mmm)

Tracking

Trunk
mozilla2.0b10
Points:
---
Bug Flags:
in-testsuite +
in-litmus -

Firefox Tracking Flags

(blocking2.0 final+)

Details

(Whiteboard: [hardblocker])

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

7 years ago
The first search a user does in the add-ons manager should show available add-ons, right now it defaults to installed add-ons which for a new user is likely to be none.
(Reporter)

Updated

7 years ago
blocking2.0: --- → final+
Whiteboard: [good first bug]

Updated

7 years ago
Assignee: nobody → paulbooker

Comment 1

7 years ago
Hi David,

Can you point me towards any documentation for getting super organized.

(Normally i help out with our community websites [Drupal] so this will be my "first" bug)

Best,
Paul Booker
Appcoast
(Reporter)

Comment 2

7 years ago
The first step is probably working out how to build Firefox. The build documentation should help out: https://developer.mozilla.org/en/Build_Documentation
(In reply to comment #2)
> The first step is probably working out how to build Firefox. The build
> documentation should help out:
> https://developer.mozilla.org/en/Build_Documentation

Justin has added another page which is more compact and easier to understand:
https://developer.mozilla.org/En/Simple_Firefox_build

Further the code which sets the local vs. remote selection should be in this file:
http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/content/extensions.js

Comment 4

7 years ago
Thanks Dave / Henrik

I'll have a go at this later this evening / tomorrow

Best, Paul

Comment 5

7 years ago
I can launch my build of firefox but i have a problem that the browser does not allow me to interact via a keyboard. Should i rebuild later today?

Best, Paul
(Reporter)

Comment 6

7 years ago
(In reply to comment #5)
> I can launch my build of firefox but i have a problem that the browser does not
> allow me to interact via a keyboard. Should i rebuild later today?

Perhaps you are building on OSX and you are running dist/bin/firefox-bin from your object directory? In which case you should instead be running dist/Minefield.app/Contents/MacOS/firefox-bin.

Otherwise it's going to be really difficult to help you debug why your build isn't working across bugzilla, I'd suggest getting onto IRC and asking for help in the #developers channel (I'm Mossop there).

This is also another good overview on the process of creating and submitting patches: https://developer.mozilla.org/En/Developer_Guide/How_to_Submit_a_Patch
(Reporter)

Updated

7 years ago
Duplicate of this bug: 613538
Duplicate of this bug: 614028

Comment 9

7 years ago
Thanks Dave,  i have now switched to Minefield.app

I'll take a look at the bug this afternoon 

Best, Paul


(In reply to comment #6)
> (In reply to comment #5)
> > I can launch my build of firefox but i have a problem that the browser does not
> > allow me to interact via a keyboard. Should i rebuild later today?
> 
> Perhaps you are building on OSX and you are running dist/bin/firefox-bin from
> your object directory? In which case you should instead be running
> dist/Minefield.app/Contents/MacOS/firefox-bin.
> 
> Otherwise it's going to be really difficult to help you debug why your build
> isn't working across bugzilla, I'd suggest getting onto IRC and asking for help
> in the #developers channel (I'm Mossop there).
> 
> This is also another good overview on the process of creating and submitting
> patches: https://developer.mozilla.org/En/Developer_Guide/How_to_Submit_a_Patch

Comment 10

7 years ago
It looks as though the file i need to work on is located at 

Mozilla//firefox/mozilla-central/objdir-ff-release/dist/Minefield.app/Contents/MacOS/chrome/toolkit/content/mozapps/extensions/extensions.js

Would you mind advising how i can clear my search history so that can i observe the initial search behavior over and over again.

Thanks Paul
(Reporter)

Comment 11

7 years ago
(In reply to comment #10)
> It looks as though the file i need to work on is located at 
> 
> Mozilla//firefox/mozilla-central/objdir-ff-release/dist/Minefield.app/Contents/MacOS/chrome/toolkit/content/mozapps/extensions/extensions.js
> 
> Would you mind advising how i can clear my search history so that can i observe
> the initial search behavior over and over again.
> 
> Thanks Paul

More likely you need to alter extensions.xul in the source directory and rebuild. Deleting localstore.rdf from your profile should reset the saved state (I recommend doing all this in a clean profile to avoid breaking your normal one).
(Reporter)

Comment 12

7 years ago
Any progress here, are you going to be able to work on this or do we need to assign it to someone else?

Updated

7 years ago
Assignee: paulbooker → nobody
(Reporter)

Updated

7 years ago
Assignee: nobody → ddahl
Assignee: ddahl → nobody
Planning to pick this one up, could we change the behaviour so that if no results are found when searching "My Add-ons", we switch to show results from "Available Add-ons"?
(Reporter)

Comment 14

7 years ago
Let's keep things simple for now and just show available add-ons by default in a new profile and then remember after that.
Created attachment 501498 [details] [diff] [review]
Changed default in extensions.xul

This patch feels.. too simple.
Assignee: nobody → mars.martian+bugmail
Status: NEW → ASSIGNED
Attachment #501498 - Flags: review?(dtownsend)
Attachment #501498 - Attachment is patch: true
Attachment #501498 - Attachment mime type: application/octet-stream → text/plain
(In reply to comment #15)
> This patch feels.. too simple.

Have you run our automated tests? Not sure, if some could fail now with this change happened. Dave can give more detailed information on it.
(Reporter)

Comment 17

7 years ago
Comment on attachment 501498 [details] [diff] [review]
Changed default in extensions.xul

You're right it is, you haven't included a test! Otherwise this is fine
Attachment #501498 - Flags: review?(dtownsend) → review-
Created attachment 501781 [details] [diff] [review]
Patch v2, adds test and fixes another.

From pushing on try, looks like this only broke browser_bug562797.js

Fixed that test and added an assertion to make sure that remote is set as default.

Pushing to try to make sure I didn't mess up anything with tests.
Attachment #501498 - Attachment is obsolete: true
Attachment #501781 - Flags: review?(dtownsend)
Comment on attachment 501781 [details] [diff] [review]
Patch v2, adds test and fixes another.

>+      var list = aManager.document.getElementById("search-list");
>+      list.ensureElementIsVisible(localFilter);
>+      EventUtils.synthesizeMouseAtCenter(localFilter, { }, aManager);
>+
>+      is(localFilter.selected, true, "Should have changed to local filter");

Beside switching to the local filter only, I think it would be good to have another test, that checks if another search then stays at the local filter.
(In reply to comment #19)
> Beside switching to the local filter only, I think it would be good to have
> another test, that checks if another search then stays at the local filter.

The next test in that file makes another search in the addons manager, which relies on the local filter being set. Technically this ensures that the local filter is set but is not explicit.

Should I add an explicit assertion that the search filter is not reset?
Ah ok. Missed that, sorry. So lets wait for the review from Dave.
Comment on attachment 501781 [details] [diff] [review]
Patch v2, adds test and fixes another.

Tests fail because it looks like the filter property persists from other tests. Taking off review until I fix that.
Attachment #501781 - Flags: review?(dtownsend)
Created attachment 502253 [details] [diff] [review]
Patch v3, fixes saved filter setting.

Removes the stored filter setting by going through the RDF data store.

The URIs added by the test ("about:addons", etc.) seem to be used elsewhere, as literals, in the test so it seemed alright to rely on them.
Attachment #501781 - Attachment is obsolete: true
Attachment #502253 - Flags: review?(dtownsend)
(Reporter)

Comment 24

7 years ago
Comment on attachment 502253 [details] [diff] [review]
Patch v3, fixes saved filter setting.

Half wonder if browser-chrome should have some code we can call to reset parts of localstore when necessary but this is good as-is for now.
Attachment #502253 - Flags: review?(dtownsend) → review+
Sweet! This looks good on try, btw.
Whiteboard: [good first bug] → [good first bug][hard blocker]
http://hg.mozilla.org/mozilla-central/rev/08babae55fb4

woo hoo!
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [good first bug][hard blocker] → [hard blocker]
Target Milestone: --- → mozilla2.0b10
Flags: in-litmus-
(Reporter)

Updated

7 years ago
Whiteboard: [hard blocker] → [hardblocker]
Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b10pre) Gecko/20110119 Firefox/4.0b10pre ID:20110119030331
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.