Closed
Bug 611459
Opened 14 years ago
Closed 14 years ago
Search should default to searching for available add-ons
Categories
(Toolkit :: Add-ons Manager, defect)
Toolkit
Add-ons Manager
Tracking
()
VERIFIED
FIXED
mozilla2.0b10
Tracking | Status | |
---|---|---|
blocking2.0 | --- | final+ |
People
(Reporter: mossop, Assigned: mmm)
References
Details
(Whiteboard: [hardblocker])
Attachments
(1 file, 2 obsolete files)
3.09 KB,
patch
|
mossop
:
review+
|
Details | Diff | Splinter Review |
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•14 years ago
|
blocking2.0: --- → final+
Whiteboard: [good first bug]
Updated•14 years ago
|
Assignee: nobody → paulbooker
Comment 1•14 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•14 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
Comment 3•14 years ago
|
||
(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•14 years ago
|
||
Thanks Dave / Henrik
I'll have a go at this later this evening / tomorrow
Best, Paul
Comment 5•14 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•14 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
Comment 9•14 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•14 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•14 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•14 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•14 years ago
|
Assignee: paulbooker → nobody
Reporter | ||
Updated•14 years ago
|
Assignee: nobody → ddahl
Updated•14 years ago
|
Assignee: ddahl → nobody
Assignee | ||
Comment 13•14 years ago
|
||
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•14 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.
Assignee | ||
Comment 15•14 years ago
|
||
This patch feels.. too simple.
Assignee: nobody → mars.martian+bugmail
Status: NEW → ASSIGNED
Attachment #501498 -
Flags: review?(dtownsend)
Updated•14 years ago
|
Attachment #501498 -
Attachment is patch: true
Attachment #501498 -
Attachment mime type: application/octet-stream → text/plain
Comment 16•14 years ago
|
||
(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•14 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-
Assignee | ||
Comment 18•14 years ago
|
||
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 19•14 years ago
|
||
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.
Assignee | ||
Comment 20•14 years ago
|
||
(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?
Comment 21•14 years ago
|
||
Ah ok. Missed that, sorry. So lets wait for the review from Dave.
Assignee | ||
Comment 22•14 years ago
|
||
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)
Assignee | ||
Comment 23•14 years ago
|
||
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•14 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+
Assignee | ||
Comment 25•14 years ago
|
||
Sweet! This looks good on try, btw.
Updated•14 years ago
|
Whiteboard: [good first bug] → [good first bug][hard blocker]
Assignee | ||
Comment 26•14 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [good first bug][hard blocker] → [hard blocker]
Target Milestone: --- → mozilla2.0b10
Updated•14 years ago
|
Flags: in-litmus-
Reporter | ||
Updated•14 years ago
|
Whiteboard: [hard blocker] → [hardblocker]
Comment 27•14 years ago
|
||
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.
Description
•