bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

Search Disabled State is Persistent even after Uninstallation

VERIFIED FIXED in fennec1.0b5

Status

Firefox for Android Graveyard
General
--
major
VERIFIED FIXED
9 years ago
5 years ago

People

(Reporter: aakashd, Assigned: vingtetun)

Tracking

Fennec 1.1
fennec1.0b5

Details

(Whiteboard: [fennecb4testday])

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

9 years ago
Build Id:

Mozilla/5.0 (X11; U; Linux armv7l; en-US; rv:1.9.2b1pre) Gecko/200910002
Fennec/1.0b4

Steps to Reproduce:
1. Go to bugzilla.mozilla.org
2. Click on Larry and save the search
3. Go to Options and disable the bugzilla search extension
4. Uninstall bugzilla search
5. go back to bugzilla.mozilla.org and install bugzilla search again
6. Go to the addons manager

Actual Results:
the bugzilla search extension is still disabled

Expected Results:
I'd expect the search extension to be set to default values once its installed again. A user is not going to re-install an extension and expect it to be uninstalled.
(Reporter)

Updated

9 years ago
tracking-fennec: --- → ?
Whiteboard: [fennecb4testday]
Does it work if you close Fennec and restart?
(In reply to comment #1)
> Does it work if you close Fennec and restart?

As I'd be more likely to agree with the blocking-fennec? if it failed after a restart.
Created attachment 405668 [details] [diff] [review]
wip

Correcting the problem by removing the disabled state once we uninstall a search engine. My question is more, should we remove the disable state once we _uninstall_ a search engine, or once we _install_ a new one?
The second sounds better for me.

Also we have a little bug with the icon of the search engine when we remove it/add it quickly: it is too fast an the icon is not fully loaded before recreating the list which lead to a row in the addons panel with a missing icon.

These code parts are related to the XXX in the code (browser.js#1401/#1407), should I consider patching them also in this bug or open a new one? Again the second sounds more logical to me.
The core issue is bug 341833 - the search service persists "disabled" state across installs/uninstalls. That patch seems like a reasonable workaround.

You should file the other problem as a separate bug.
Comment on attachment 405668 [details] [diff] [review]
wip

Add a comment? Something like:

Make sure the engine isn't hidden before removing it, to make sure it's visible if the user later re-adds it (works around bug 341833)
Attachment #405668 - Flags: review?(mark.finkle) → review+
Created attachment 407034 [details] [diff] [review]
Patch

Adding gavin's comment. I don't think I can made something better than it.
Assignee: nobody → 21
Attachment #405668 - Attachment is obsolete: true
pushed:
https://hg.mozilla.org/mobile-browser/rev/33119772b872
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → B5
(Reporter)

Comment 8

9 years ago
verified FIXED on builds:

Mozilla/5.0 (X11; U; Linux armv7l; en-US; rv:1.9.2b1pre) Gecko/20091021
Fennec/1.0b5pre

and

Mozilla/5.0 (X11; U; Linux armv6l; en-US; rv:1.9.3a1pre) Gecko/20091021
Fennec/1.0b5pre
Status: RESOLVED → VERIFIED
tracking-fennec: ? → ---
You need to log in before you can comment on or make changes to this bug.