Closed Bug 1449681 Opened 2 years ago Closed 2 years ago

Search engine installation via a web api is not blocked by the 'SearchEngines' policy

Categories

(Firefox :: Enterprise Policies, defect)

61 Branch
defect
Not set

Tracking

()

VERIFIED FIXED
Firefox 61
Tracking Status
firefox60 --- verified
firefox61 --- verified

People

(Reporter: Abe_LV, Assigned: bytesized)

References

Details

Attachments

(1 file)

Steps to reproduce:

Screen capture- https://testing-1.tinytake.com/sf/MjQ3NzEzN183NDY0MjM3

1. Enable the policy by using this JSON:
{
  "policies": {
    "SearchEngines": {      
      "PreventInstalls": true
    }
  }
}

2. Start Firefox from a new profile
3. Customize Firefox and drag search-bar next to the urlbar
4. Go to https://bugzilla.mozilla.org/
5. Verify "Add Bugzilla@Mozilla" option is NOT available in the search bar

Actual Result:
A user can still install search engines while "PreventInstalls" is set to true.

Expected Result:
The 'SearchEngines' policy should prevent search engine installations when "PreventInstalls" is set to true.
Flags: needinfo?(ksteuber)
Flags: needinfo?(felipc)
It looks like this disallow needs to be propagated to the content processes. This simple patch should fix the problem assuming that |Services.search.init| callbacks will be called before any content processes are created.

Florian - Can you verify the assumption that I am making? Will |Services.search.init| callbacks be called before any content processes are created?
Assignee: nobody → ksteuber
Flags: needinfo?(ksteuber)
Flags: needinfo?(florian)
Flags: needinfo?(felipc)
(In reply to Kirk Steuber [:bytesized] from comment #2)
> Will
> |Services.search.init| callbacks be called before any content processes are
> created?

No. Actually, this should rarely be the case, as we create the search service after first paint, and the first content process is created before first paint.
Flags: needinfo?(florian)
Attachment #8963305 - Flags: review?(felipc)
Comment on attachment 8963305 [details]
Bug 1449681 - Fix bug where opensearch API is not always successfully blocked by policy

https://reviewboard.mozilla.org/r/232212/#review237750
Attachment #8963305 - Flags: review?(felipc) → review+
Pushed by ksteuber@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/d929540bc238
Fix bug where opensearch API is not always successfully blocked by policy r=Felipe
https://hg.mozilla.org/mozilla-central/rev/d929540bc238
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 61
Comment on attachment 8963305 [details]
Bug 1449681 - Fix bug where opensearch API is not always successfully blocked by policy

Approval Request Comment
[Feature/Bug causing the regression]: Enterprise Policy Engine
[User impact if declined]: Policy will inconsistently disable the opensearch API
[Is this code covered by automated tests?]: Yes
[Has the fix been verified in Nightly?]: Yes
[Needs manual test from QE? If yes, steps to reproduce]: To be verified by Abe
[List of other uplifts needed for the feature/fix]: None
[Is the change risky?]: Minimal Risk
[Why is the change risky/not risky?]: Only affects the behavior of users with this enterprise policy enabled
[String changes made/needed]: None
Attachment #8963305 - Flags: approval-mozilla-beta?
We verified this on the latest nightly using JSON policy format and it is verified as fixed.
Test cases and runs are here- https://testrail.stage.mozaws.net/index.php?/plans/view/8760
Status: RESOLVED → VERIFIED
Comment on attachment 8963305 [details]
Bug 1449681 - Fix bug where opensearch API is not always successfully blocked by policy

Enterprise fix verified by QA. Approved for 60.0b9.
Attachment #8963305 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
We tested this on beta and it is verified as fixed based on "Fix bug where opensearch API is not always successfully blocked by policy."
Test cases and runs are here- https://testrail.stage.mozaws.net/index.php?/plans/view/8760
You need to log in before you can comment on or make changes to this bug.