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

Upcoming Bugzilla API and Bot Changes

[Emma Humphries]

## Summary ##

During 2020, the Bugzilla team will be making several changes to improve
security and performance for our users who rely on APIs and automation. We
want you to know about them so you can start preparations.

## AutoNag  ##

AutoNag is a service which runs a Bugzilla query and then takes actions on
the results. It’s used to notify teams about untriaged bugs, close
intermittent test failures, clean up bugs, and other tasks.

You can write your own scripts, following the guidelines in the repository,
or file an issue to request one.

If you want to set up a rotation of people to triage a component, AutoNag
will enable that as well. You need to set up a Google Calendar or JSON file
with a schedule of people triaging bugs first.

If AutoNag does not meet your requirements and you run your own bots and
scripts, please take note about upcoming changes.

- https://wiki.mozilla.org/Release_Management/autonag
- https://github.com/mozilla/relman-auto-nag

## Bot guidelines ##

If you run a script or bot that uses the Bugzilla API, make sure it is in
our registry.

Check the registry page because it has requirements we expect all bots and
scripts to follow by mid-2020: including standard naming, using api keys,
and our REST interface.

- https://bmo.readthedocs.io/en/latest/api/index.html
- https://wiki.mozilla.org/BMO/Bot_Registry

If you use our old APIs you need to know about their retirement.

## Old interfaces going away ##

We plan to shut down the JSONRPC (https://bugzilla.mozilla.org/jsonrpc.cgi),
XMLRPC (https://bugzilla.mozilla.org/xmlrpc.cgi), and BzAPI (
https://bugzilla.mozilla.org/bzapi/) interfaces by the end of June, 2020.

If you use one of these, you will need to update your code to use REST.
That interface is documented, and if you find problems or issues with it
please file a bug.

- https://bmo.readthedocs.io/en/latest/api/
-
https://bugzilla.mozilla.org/enter_bug.cgi?product=bugzilla.mozilla.org=API

This would be a good time to move the definition of the base URL you use to
access our API to a configuration in your applications using it.

- https://bugzilla.mozilla.org/rest

Questions?

Please seek the BMO team out on Slack and Matrix.

Thanks,

Emma Humphries, on behalf of the BMO team
___
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
> 

Firefox Profiler will see some downtime on friday and saturday

[Julien Wajsberg]

Hey folks,

(sorry for the cross-posting!)

On the coming friday and saturday (pacific time), we'll carry out an 
operation to transfer all the stored profiles to the mozilla-owned cloud 
account. Unfortunately, to properly handle this operation we'll need to 
turn off the server part that handles the profile publishing process. 
This means that on friday and possibly on saturday you won't be able to 
publish new profiles.


As part of the transfer we'll also temporarily remove the existing GCP 
bucket. This means that on saturday you won't be able to access existing 
published profiles.


If everything goes according to our plan (famous last words), this will 
be finished on sunday.


For some more detailed information you can look at our documentation in 
https://profiler.firefox.com/docs/#/./cloud-migration.


If you absolutely need the profiler working on these days, please speak 
up now :-)


Cheers,

--
Julien

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