Re: Intent to ship: Autodiscovery of WebExtension search engines

[Dale Harvey]

OpenSearch is not a standard and as far as I understand it almost no  wrote:

> I would also like to mirror the previous comments: Why do we need to
> expose this new non-standard feature to the web? Can't we just
> transform OpenSearch XML internally to the new WebExtension format?
>
> On Wed, Feb 26, 2020 at 1:17 PM Henri Sivonen 
> wrote:
> >
> > On Tue, Feb 25, 2020 at 10:04 PM Dale Harvey 
> wrote:
> > > Yes,  extensions that only define a new search engine will be
> permitted,
> > > the extension will not be able to do anything else.
> >
> > What capabilities do search engine-only WebExtensions have that
> > OpenSearch doesn't provide?
> >
> > --
> > Henri Sivonen
> > hsivo...@mozilla.com
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Autodiscovery of WebExtension search engines

[Tom Schuster]

I would also like to mirror the previous comments: Why do we need to
expose this new non-standard feature to the web? Can't we just
transform OpenSearch XML internally to the new WebExtension format?

On Wed, Feb 26, 2020 at 1:17 PM Henri Sivonen  wrote:
>
> On Tue, Feb 25, 2020 at 10:04 PM Dale Harvey  wrote:
> > Yes,  extensions that only define a new search engine will be permitted,
> > the extension will not be able to do anything else.
>
> What capabilities do search engine-only WebExtensions have that
> OpenSearch doesn't provide?
>
> --
> Henri Sivonen
> hsivo...@mozilla.com
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Autodiscovery of WebExtension search engines

[Henri Sivonen]

On Tue, Feb 25, 2020 at 10:04 PM Dale Harvey  wrote:
> Yes,  extensions that only define a new search engine will be permitted,
> the extension will not be able to do anything else.

What capabilities do search engine-only WebExtensions have that
OpenSearch doesn't provide?

-- 
Henri Sivonen
hsivo...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Autodiscovery of WebExtension search engines

[Dale Harvey]

Sorry I had replied but only just realised the discussion had been taken
off list

> Does this code enforce that the .xpi we download and attempt to install
is actually a search type and not an arbitrary WebExtension

Yes,  extensions that only define a new search engine will be permitted,
the extension will not be able to do anything else.

> "Yes" meaning "required", I hope.

Yes https is required here

> Were there other alternatives considered which do not require modifying
web pages with a new meta tag?

Nope, this feature was planned mostly as a 1:1 equivalent implementation of
the current opensearch implementation to maintain parity between
webextensions and opensearch

> If you _do_ invent a new one shared with other browser vendors, please
> don't use an "x-" prefix in anything new.

Thanks, I got notice of others concerns about this as well and have been
looped in to discuss this more with standards before shipping. Once we have
something agreeable will make sure to update this thread.

> I realize that getting this kind of feedback at the time of an intent to
ship is at best extremely unsettling, because you've probably done a lot of
work on this, and for that I apologize.

Not at all, thanks to everyone for their feedback, happy to make sure we
get this right before shipping (or not).

Cheers
Dale

On Wed, 19 Feb 2020 at 20:28, Adam Roach  wrote:

> On 2/14/2020 5:05 PM, Daniel Veditz wrote:
> > On Fri, Feb 14, 2020 at 11:50 AM Dale Harvey 
> wrote:
> >
> >> We’re proposing a new mime-type [...]: “x-xpinstall” for WebExtension
> >> search
> >> engines. Example:  > trigger extension installs from link clicks. Since standard media-type
> > syntax is "/" some authors will tend to fill in the
> > "missing" bit and get it wrong, and others will complain that the syntax
> is
> > non-standard and broken.
> >
> > Does this code enforce that the .xpi we download and attempt to install
> is
> > actually a search type and not an arbitrary WebExtension? If any
> extension
> > type will work then re-using the full application/x-xpinstall is
> > appropriate, but that sounds like it would go against user expectation
> and
> > might trick users into doing something dangerous. "This page would like
> to
> > install 'Steal all your data from every page search engine'. OK?" If the
> > code does enforce only search type add-ons will it be confusing to use
> the
> > generic media-type? Or maybe it's OK anyway, since rel="search" is
> required
> > and can be taken as requiring that subset.
> >
> > If you _do_ invent a new one shared with other browser vendors, please
> > don't use an "x-" prefix in anything new.
> > https://tools.ietf.org/html/rfc6648 [2012] (hey -- our very own St.
> Peter)
>
>
> I had a response composed, and then realized that Dan had covered most
> of what I wanted to say. The only additional point I would like to make
> is: unless you're re-using a media type already in use (e.g.,
> application/x-xpinstall), or planning to run this through a standards
> process first, this should look something like
> "application/vnd.mozilla.webextension." See
>  for
> details.
>
> /a
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Autodiscovery of WebExtension search engines

[Dale Harvey]

On Thu, 20 Feb 2020 at 00:17, Daniel Veditz  wrote:

> On Wed, Feb 19, 2020 at 2:10 PM Dale Harvey  wrote:
>
>> > If you _do_ invent a new one shared with other browser vendors, please
>> > don't use an "x-" prefix in anything new.
>>
>> Thanks, I got notice of others concerns about this as well and have been
>> looped in to discuss this more with standards before shipping. Once we have
>> something agreeable will make sure to update this thread.
>>
>
> If the file format is a Gecko-specific standard add-on .xpi (of a specific
> type) then it's not going to be supported by other browsers (each browser
> has their own signature requirements even though all Web Extensions are
> basically ZIP archives). Since it is the same file format and extension you
> might as well use the historical "application/x-xpinstall" we use for
> add-ons. It's not making the "X-" Content-Type problem any worse, and for
> sites that already have a type mapping for .xpi (granted, not many) they
> won't have to jump through hoops setting up a different one for use
> depending on where it's served. If you do use a different Content-Type then
> you should probably use something other than .xpi for the file extension,
> even if it's the same inside.
>
> -Dan Veditz
>

Cheers, I met with Anne about this today and think you are right here.
These are very similiar to links to WebExtensions and reusing the existing
type makes sense from a standards + developers perspective. I will close
out this one and send out a new Intent to Ship with the corrected details.

Thanks for your feedback
Dale
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Autodiscovery of WebExtension search engines

[Daniel Veditz]

On Wed, Feb 19, 2020 at 2:10 PM Dale Harvey  wrote:

> > If you _do_ invent a new one shared with other browser vendors, please
> > don't use an "x-" prefix in anything new.
>
> Thanks, I got notice of others concerns about this as well and have been
> looped in to discuss this more with standards before shipping. Once we have
> something agreeable will make sure to update this thread.
>

If the file format is a Gecko-specific standard add-on .xpi (of a specific
type) then it's not going to be supported by other browsers (each browser
has their own signature requirements even though all Web Extensions are
basically ZIP archives). Since it is the same file format and extension you
might as well use the historical "application/x-xpinstall" we use for
add-ons. It's not making the "X-" Content-Type problem any worse, and for
sites that already have a type mapping for .xpi (granted, not many) they
won't have to jump through hoops setting up a different one for use
depending on where it's served. If you do use a different Content-Type then
you should probably use something other than .xpi for the file extension,
even if it's the same inside.

-Dan Veditz
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Autodiscovery of WebExtension search engines

[Adam Roach]

On 2/14/2020 5:05 PM, Daniel Veditz wrote:

On Fri, Feb 14, 2020 at 11:50 AM Dale Harvey  wrote:


We’re proposing a new mime-type [...]: “x-xpinstall” for WebExtension
search
engines. Example: 

This is confusingly similar to "application/x-xpinstall" which we use to
trigger extension installs from link clicks. Since standard media-type
syntax is "/" some authors will tend to fill in the
"missing" bit and get it wrong, and others will complain that the syntax is
non-standard and broken.

Does this code enforce that the .xpi we download and attempt to install is
actually a search type and not an arbitrary WebExtension? If any extension
type will work then re-using the full application/x-xpinstall is
appropriate, but that sounds like it would go against user expectation and
might trick users into doing something dangerous. "This page would like to
install 'Steal all your data from every page search engine'. OK?" If the
code does enforce only search type add-ons will it be confusing to use the
generic media-type? Or maybe it's OK anyway, since rel="search" is required
and can be taken as requiring that subset.

If you _do_ invent a new one shared with other browser vendors, please
don't use an "x-" prefix in anything new.
https://tools.ietf.org/html/rfc6648 [2012] (hey -- our very own St. Peter)



I had a response composed, and then realized that Dan had covered most 
of what I wanted to say. The only additional point I would like to make 
is: unless you're re-using a media type already in use (e.g., 
application/x-xpinstall), or planning to run this through a standards 
process first, this should look something like 
"application/vnd.mozilla.webextension." See 
 for 
details.


/a

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Autodiscovery of WebExtension search engines

[Ehsan Akhgari]

Hi Dale,

It seems that this feature is not being developed with the hope of it
turning into a cross-browser autodiscovery of search extensions in the
future.  With that in mind, I'd like to ask if it is really necessary to
expose a new meta tag to the web platform, given the unclear path to the
adoption of this feature for another browser engine (e.g. Servo, Blink or
WebKit.)  Per our API exposure guidelines <
https://wiki.mozilla.org/ExposureGuidelines#When_is_a_feature_ready_to_ship.3F>
it doesn't appear that this feature meets the criteria for a new platform
feature that we should ship.

Were there other alternatives considered which do not require modifying web
pages with a new meta tag?  For example, one simple idea that comes to mind
is allowing extra metadata in the definition of search engine extensions
which indicates the URL for the equivalent OpenSearch service and matching
that metadata with the OpenSearch annotations found in the existing pages
that users browse which have OpenSearch annotations.  (This idea itself is
probably not useful since I don't know your exact requirements, suggesting
it mostly as a way to open a discussion.)

I realize that getting this kind of feedback at the time of an intent to
ship is at best extremely unsettling, because you've probably done a lot of
work on this, and for that I apologize.

Thanks for your consideration,
Ehsan

On Fri, Feb 14, 2020 at 2:50 PM Dale Harvey  wrote:

> Summary: Since Firefox 57, users have been able to install additional
> search engines in the shape of a WebExtension[1] from addons.mozilla.org
> (AMO), whereas this used to only be possible using the OpenSearch XML
> format[2]. Since Firefox 68, all the search engines we distribute are
> WebExtensions[3].
>
> Websites are currently able to advertise their search engine to the
> browser[4], but this is not yet possible for WebExtension search engines.
>
> We’re proposing a new mime-type to be supported for 
> tags, other than “application/opensearchdescription+xml”: “x-xpinstall” for
> WebExtension search engines. Example:  href=“https://addons.mozilla.org//firefox/addon/”/>.
>
> NB: we are aware that the (pseudo-)mime-type “x-xpinstall” is not
> particularly friendly to cross-browser adoption, so we’re very much open to
> suggestions! Possible alternatives might be “x-webext” or “x-webextension”.
> Please reply in this thread with your ideas.
>
> NB2: We are collaborating with the addons team at Mozilla to consider
> autodiscovery of addons in general, using this mechanism, but haven’t
> reached a point where we can announce something concrete.
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1562657
>
> Standard: The WebExtension API documentation can be found at [4]. There is
> no standard known to us for this feature and we are not collaborating with
> other browsers at this point (see ‘Other browsers’ below).
>
> Platform coverage: This feature will be available on Firefox Desktop, on
> all supported platforms.
>
> Preference: We intend to ship this feature pref'd on by default, but it may
> be disabled by setting the “browser.search.webext.discovery.enabled" pref
> to ‘false’.
>
> DevTools bug: N/A.
>
> Other browsers: We haven’t been in active discussion with other browser
> vendors regarding this feature, since our primary motivation for moving to
> WebExtensions wholesale is motivated by our fight against malware and
> search hijackers. We are open to any type of collaboration with other
> browsers regarding this feature and WebExtension search engines in the
> broadest sense.
>
> web-platform-tests: (web-)Search has never been considered an official part
> of the web-platform and the OpenSearch specification hasn’t seen any major
> updates for over a decade. Test coverage is provided by XPCShell and
> Mochitest-browser tests written specifically for the ‘search’ toolkit
> component.
>
> Secure contexts: Yes.
>
> Is this feature enabled by default in sandboxed iframes? Yes, this feature
> does not have any impact on sandboxed iframes.
>
> As of Firefox 75, the intent is to turn WebExtension search engine
> discovery on by default on all platforms. It has been developed behind the
> browser.search.webext.discovery.enabled preference. See above for the
> shipping status in other browsers.
>
> Product: Mike Connor.
>
> Bug to implement and turn on by default:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1562657.
>
> [1]
>
> https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/chrome_settings_overrides
>
> [2] https://developer.mozilla.org/en-US/docs/Web/OpenSearch
>
> [3] See https://bugzilla.mozilla.org/show_bug.cgi?id=1486820 where we
> converted all our own, built-in engines to WebExtensions.
>
> [4]
>
> https://developer.mozilla.org/en-US/docs/Web/OpenSearch#Autodiscovery_of_search_plugins
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> 

Re: Intent to ship: Autodiscovery of WebExtension search engines

[Daniel Veditz]

On Fri, Feb 14, 2020 at 11:50 AM Dale Harvey  wrote:

> We’re proposing a new mime-type [...]: “x-xpinstall” for WebExtension
> search
> engines. Example: /" some authors will tend to fill in the
"missing" bit and get it wrong, and others will complain that the syntax is
non-standard and broken.

Does this code enforce that the .xpi we download and attempt to install is
actually a search type and not an arbitrary WebExtension? If any extension
type will work then re-using the full application/x-xpinstall is
appropriate, but that sounds like it would go against user expectation and
might trick users into doing something dangerous. "This page would like to
install 'Steal all your data from every page search engine'. OK?" If the
code does enforce only search type add-ons will it be confusing to use the
generic media-type? Or maybe it's OK anyway, since rel="search" is required
and can be taken as requiring that subset.

If you _do_ invent a new one shared with other browser vendors, please
don't use an "x-" prefix in anything new.
https://tools.ietf.org/html/rfc6648 [2012] (hey -- our very own St. Peter)

Secure contexts: Yes.
>

"Yes" meaning "required", I hope.

Is this feature enabled by default in sandboxed iframes? Yes, this feature
> does not have any impact on sandboxed iframes.
>

Currently the feature doesn't seem to work in regular frames, only the
top-level document, so I don't know why it would work in sandboxed frames.
data:text/html,https://www.merriam-webster.com/>
-Dan Veditz
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform