Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revert Mozilla search engine handling. #699

Closed
wolfbeast opened this issue Aug 6, 2018 · 4 comments

Comments

Projects
None yet
2 participants
@wolfbeast
Copy link
Member

commented Aug 6, 2018

https://bugzilla.mozilla.org/show_bug.cgi?id=1203167 changed the handling so the behavior is all sorts of a PITA for power users to deal with.

The rationale was: "Once the search cache is no longer optional (bug 1203161), we could use the cache file as the place to store user-installed engines."

This causes issues: The cache file is supposed to be just that: a (volatile) cache file for quick init of the search engines. If there's a problem in the json structure, not only does it fail to load, it will also be unrecoverable, leading to user data (added/custom search engines) being lost. In addition (and that is something I'd want to revert short-term), the custom lz4 compression on it makes it impossible to do anything with the file except from within an extension (that can use lz4.js) and on top a JS implementation of lz4 compression to me seems like a bad idea anyway.

Of note: a hash was also added to "prevent tampering" but that is exactly the kind of thing power users want to do to make quick edits to search plugin definitions. A hash should still be kept on the custom meta data so malicious parties can't change the search engine presence and order/keywords externally, but the engine definitions themselves don't need to be "guarded" or locked down this way.

Bottom line is it all becomes obscured and un-editable this way, unnecessarily so.

This change needs to be reverted, so we can get back to having a search.json cache in its original intended purpose, and having serialized XML files in the profile that are the cache's "source" for custom/added search engines, getting everything in the clear and in plain sight, unobscured.

Tasks:

  • Land modified Gecko/44 search engine handling for Pale Moon 28 use ahead of final release
  • Convert search handling for other applications (land in tandem):
    • Revert search.json.mozlz4 to search.json/search-metadata.json/xml for other applications
    • Write a migrator that reads (and deletes) search.json.mozlz4 and writes the target format files
      This should be an overwriting migrator to prevent duplicates.
  • Remove conditionals and always use the reverted method for all applications
  • Remove the Gecko/52 native handling
@mattatobin

This comment has been minimized.

Copy link
Member

commented Aug 6, 2018

Ahead of Pale Moon 28's release I want to include a slightly modified version of the gecko/44 search service which seems to be the sweet spot that just works with UXP but also has everything we want.

Basilisk and Iceweasel will have to modify the locale makefile and the preference referenced dtd file(s) to conform to the "old" way. This can be done after a migration routine is devised in follow up issues promoting this to a meta issue.

After which the "native" search service code can be purged.

@mattatobin

This comment has been minimized.

Copy link
Member

commented Aug 6, 2018

@mattatobin

This comment has been minimized.

Copy link
Member

commented Apr 21, 2019

At this point, I am likely going to move the ESR52 searchservice to Basilisk and not build the older incarnation if Basilisk or Hyperbola

tl;dr Everything uses the older incarnation so screw the extra work.

@mattatobin mattatobin added App: Basilisk and removed Meta-issue labels Apr 21, 2019

@mattatobin

This comment has been minimized.

Copy link
Member

commented Apr 23, 2019

^ Did that

@mattatobin mattatobin closed this Apr 23, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.