PSA: Removing the Pointerlock permission UI

[Dale Harvey]

In https://bugzilla.mozilla.org/show_bug.cgi?id=1273351 I am working on
removing the pointerlock permissions UI, now instead of a doorhanger
permission that the user needs to respond to before entering pointerlock,
the pointer lock will be granted with a warning given to the user
explaining how to exit, similiar to fullscreen and in alignment with
chromes implementation.

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

Intent to implement: Ability to surpress default contextmenu items

[Dale Harvey]

Application developers have the ability to specify additional menuitems for
contextmenus via
http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#context-menus
however they are currently shown in addition to the default items, we are
looking to implement an optional attribute that allows authors to disable
the default context menu items so only the applications items are shown.
This is primarily targeted for Firefox OS, I believe Jonas will be looking
to add it to the official spec.

The name / value of the attribute is under discussion


  


looks like the most likely candidate.

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

Re: Intent to implement: Ability to surpress default contextmenu items

[Dale Harvey]

Google docs is a very good use case, In a previous job I implemented a web
based spreadsheet and we also had to implement our own contextmenu and
surpress the default because of the way that it conflicts.

Its a catch 22, applications will continue to hijack the default menu
unless the functionality is improved, but the functionality wont improve if
nobody is using it.

However thinking about the use case that was presented for us on Firefox
OS, I am not entirely convinced that we need to surpress the default
context menu items, I think we can provide better UX that doesnt leave the
user with too many + confusing options so I have asked Jonas about closing
the bug that was opened to implement this.


On 2 July 2014 13:30, Ehsan Akhgari  wrote:

> On 2014-07-02, 4:16 PM, Dao wrote:
>
>> On 02.07.2014 20:51, Ehsan Akhgari wrote:
>>
>>> We can still show the UA
>>> context menu if you hold down shift like we do today though.
>>>
>>
>> What would be the equivalent to that on Firefox OS?
>>
>
> I don't think we have a similar way to do this in Firefox OS.
>
> Cheers,
> Ehsan
>
> ___
> 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 support apple-touch-icon with Browser API

[Dale Harvey]

We specifically chose a User Agent to something compatible with our Android
release to get more compatible websites, despite the "standard" way would
be to not do browser sniffing. Not only that, but we do spoof our User
Agent to specific websites exactly so we get a more compatible page to
improve the users experience right now.

Both of these are temporary solutions that have large improvements on user
experience with a path to degrading the functionality in favour of web
standards. Both are solutions that have been similiarly adopted by other
vendors.

So there isnt much difference between this and other compatibility problems


On 28 July 2014 16:59, Anthony Ricaud  wrote:

> I don't think we should implement this. Surely it provides a better user
> experience but that's always the tradeoff when considering implementing
> proprietary features from other vendors. If we changed our user-agent to
> something that matches Android or iOS devices, we would get mobile versions
> of websites more often and provide a better experience. Instead, we have a
> webcompat team that reach outs websites to help them follow standards. Same
> thing with implementing webkit prefixed CSS properties.
>
> Why is this different than our other compatibility problems?
>
> On 25/07/14 06:37, Alive wrote:
>
>> Hi folks,
>>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=921014 is tracking: support
>> link rel="apple-touch-icon” in our browser API.
>> With this we could start to fetch and display the "apple" format icon in
>> FxOS or any app using browser API.
>>
>> There are already some opinions about we should or we shouldn’t implement
>> it in the bug comments.
>>
>> This mail is to bring this topic to more people.
>>
>> Thanks.
>> --
>> Alive C. Kuo, Firefox OS, Senior Software Engineer at Mozilla Taiwan,
>> Taipei office.
>>
>>
> ___
> 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: Deprecate geolocation and getUserMedia() for unauthenticated origins

[Dale Harvey]

On 28 September 2014 17:38, Anne van Kesteren  wrote:

> On Sun, Sep 28, 2014 at 3:08 PM, Karl Dubost  wrote:
> > Imagine if I home developing my own little Web app on my computer, I
> need to get through the hops of deploying TLS.
>
> For testing purposes you can get by without TLS just fine. As far as I
> know the definition of authenticated origin includes localhost.
>
>
What is the definition of 'authenticated origins', particularly when
dealing with localhost, I am worried that mine and a lot of devs setup
includes setting up a local /etc/hosts file and working in convenient
environment in which it will be no longer be possible. Similiarly when
setting up ad hoc local networks or creating a standalone intranet,
something I do fairly regularly for demos at a conference, hackdays etc

This has already been a major painpoint as the author of an IndexedDB
library I am fairly constantly asked questions of my library doesnt work
when server from file://index.html since the security model deals around
the host, it makes things harder for all developers, new ones especially.

There is a solution for transmitting private information over the network,
and I believe the responsibility is on content authors to decide when that
is appropriate and when it is not and not the standards bodies. I agree
that any site in production on the live internet transferring users
information should be using https, but every website doesnt follow that use
case.

>
>
> > Asking everyone to adopt TLS is a bit like asking everyone to switch to
> XML.
>
> Not really. XML requires redesigning your entire application from the
> ground up. Adding TLS is a little bit of configuration. Completely
> different ballpark.
>
>
> > It doesn't visibly and directly improve the life of people. In the big
> scheme of things, it gives an additional layer of security on their
> communications, but not privacy.
>
> It gives privacy from passive and active network attackers, no?
>
>
> > Even more so, telling to people that they have more privacy because the
> communication is secure end-to-end is deeply misleading. Secured
> geolocations end-to-end to an aggregator such as FourSquare, Google,
> Facebook, etc. doesn't change anything about your privacy.
>
> That's a question of trust, not one of privacy.
>
>
> --
> https://annevankesteren.nl/
> ___
> 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: Deprecate geolocation and getUserMedia() for unauthenticated origins

[Dale Harvey]

> There's a host of problems when you're using file URLs.

pun intended? :)

But I agree, for a long time developing off file:/// is pretty much
impossible and developers are now required to start a server in order to
build or use their entirely offline completely unconnected application, is
it really a surprise that noone is building offline capable web apps? 'have
an option / extention' is a weak workaround that puts the onus on often the
user(!) and the developer to be able to work around restrictions in the
base platform that shouldnt exist in the first place.

Similiarly with gUM, bluetooth, serial ports and tcp socket apis all
enabling more peer to peer (and offline capable) it seems entirely the
wrong approach to have the functionality of the base platform restricted to
a single end transport mode.


On 29 September 2014 10:06, Anne van Kesteren  wrote:

> On Mon, Sep 29, 2014 at 8:01 AM, Dale Harvey  wrote:
> > What is the definition of 'authenticated origins', particularly when
> dealing
> > with localhost,
>
> https://w3c.github.io/webappsec/specs/mixedcontent/#authenticated-origin
>
>
> > This has already been a major painpoint as the author of an IndexedDB
> > library I am fairly constantly asked questions of my library doesnt work
> > when server from file://index.html since the security model deals around
> the
> > host, it makes things harder for all developers, new ones especially.
>
> Maybe browsers should have some kind of developer extension that
> allows you to temporarily read the file system through localhost.
> There's a host of problems when you're using file URLs.
>
>
> --
> https://annevankesteren.nl/
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: treating B2G device tests as tier 1

[Dale Harvey]

On 16 October 2014 20:55, Ehsan Akhgari  wrote:

> On 2014-10-16, 1:52 PM, Bobby Holley wrote:
>
>> On Thu, Oct 16, 2014 at 7:04 PM, Ehsan Akhgari > > wrote:
>>
>> I don't think it's reasonable to assume that the person doing the
>> backout has the time or the expertise to add a test for the broken
>> functionality.
>>
>>
>> Not the sheriff certainly, but I think if the regression is severe
>> enough to warrant this action, the product owners (who are generally the
>> ones who request the backout) can find the resources to make that happen.
>>
>
> Who are the product owners exactly?  Usually what happens in these cases
> is some discussion on IRC, followed by trying to ping the author/reviewer,
> followed by a backout either by a sheriff or another individual such as
> myself.
>

>  There will be situations where this is unrealistically difficult for one
>> reason or another. But I'd rather put the onus on the product owners to
>> ask for that exception, and presumably offer human resources to help the
>> developer update and test their patch.
>>
>
> Again, I'm not sure who specifically you're referring to as the bearer of
> this responsibility.
>
> > If a team pulls this card, they
>
>> should have a responsibility to help get the patch relanded in a timely
>> manner.
>>
>
> I disagree.  If someone breaks Nightly on desktop for example to an extent
> where it cannot be used for dogfooding, and I back them out to help out our
> Nightly users and keep the testing product usable so that other regressions
> can be caught with it, why should I feel responsible for relanding their
> patch in a timely manner?


The "someone" is the person that wrote the feature that was broken but no
tests caught it

I believe the general idea is that as a peer / module owner / product
owner, I have the responsibility to write tests that ensure my feature
works, and if it is broken by upstream changes that landed because
automation didnt find anything wrong with it, then its my responsibility to
ensure that tests are written so it doesnt get regressed in the same way
again and automation can catch it.

Otherwise with no visibility I am putting the reponsibility onto every
other upstream developer to hopefully not break my code without any context
for them to even know when they have done so.

This is summed up in the meme:
http://mozillamemes.tumblr.com/post/26210699924/you-reap-what-you-sow


>
> ___
> 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: http-schemed URLs and HTTP/2 over unauthenticated TLS

[Dale Harvey]

> But that would no longer be about HTTP. At least as far as the things
> we've been talking about exposing in browsers are concerned.

Lots of things speak over http that arent (permenently) connected to the
global web / dns, why is that not of any concern?

On 21 November 2014 16:09, Anne van Kesteren  wrote:

> On Fri, Nov 21, 2014 at 3:53 PM, Patrick McManus 
> wrote:
> > nosslsearch.google.com is an example of the weight of regulatory
> compliance
> > in action. Google talks loudly about all https (and has the leading track
> > record), yet there it is. And google isn't special in that regard.
>
> Why would they be allowed to use OE?
>
>
> >> I.e. Let's Encrypt going away somehow?
> >
> > More generally being dependent on a CA is an additional third party
> > operational risk when comparing http:// vs https://.. you're already
> > dependent on your DNS provider and an ISP and now your fate is also
> linked
> > to the CA that signed your cert too. e.g. at the most basic level not
> > revoking it on you - but also not doing something dumb unrelated to you
> > that gets the signing cert your CA used tossed out of UAs (again).
>
> That risks seems tiny compared to the risk of having an end user
> man-in-the-middled.
>
>
> >>> non-access to webpki.
> >>
> >> Does this mean intranets?
> >
> > mostly.. but more generally things that don't bind well to the global dns
> > that the webpki relies on.. so potentially peer to peer and mesh
> > interactions too..
>
> But that would no longer be about HTTP. At least as far as the things
> we've been talking about exposing in browsers are concerned.
>
>
> --
> https://annevankesteren.nl/
> ___
> 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: Can we make try builds default to a different profile than Nightly/Aurora/Beta/Release builds?

[Dale Harvey]

+1000

I am constantly killing my profile by downgrading it when I need to test
something on Firefox Stable. Switching between Chrome releases couldnt be
easier but even as a Firefox Dev switching between profiles when testing a
different version is a nightmare, I cant imagine how unfriendly it is for
typical web developers.


On 8 April 2015 at 20:52, Jonathan Griffin  wrote:

> There is also an old, unmaintained GUI for managing profiles:
> https://developer.mozilla.org/en-US/docs/Profile_Manager
>
> It still works, although there are a few bugs.  It may be an improvement
> over command-line arguments for less technical users.
>
> Jonathan
>
> On Wed, Apr 8, 2015 at 12:49 PM, Gavin Sharp  wrote:
>
> > I think you can get this fairly easily by just changing one of the
> > values (Vendor or Name) in build/application.ini such that a different
> > profile folder is used.
> >
> > Gavin
> >
> > On Wed, Apr 8, 2015 at 12:28 PM, L. David Baron 
> wrote:
> > > On Wednesday 2015-04-08 12:08 -0700, Seth Fowler wrote:
> > >> I think one way we could reduce the burden on users would be to just
> > make try builds default to a different profile than channel builds.
> > >
> > > Is there a simple patch one could push to change this default, and
> > > just include on any try pushes where you need this behavior?
> > >
> > > I'm a little nervous about making try builds differ from other
> > > trees, since that just increases the risk of bustage (or bugs in
> > > testing) that shows up in one place but not the other.
> > >
> > > -David
> > >
> > > --
> > > 𝄞   L. David Baron http://dbaron.org/   𝄂
> > > 𝄢   Mozilla  https://www.mozilla.org/   𝄂
> > >  Before I built a wall I'd ask to know
> > >  What I was walling in or walling out,
> > >  And to whom I was like to give offense.
> > >- Robert Frost, Mending Wall (1914)
> > >
> > > ___
> > > 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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Voting in BMO

[Dale Harvey]

I have seen voting being recommended as alternative to +1's which is a
plus, we have never used them to prioritise although not sure our area of
bugs is popular enough to be using votes in that way.

As a developer of a bugzilla client however I have see a major missing
feature being the ability to favourite bugs in bugzilla., not to cc and get
a baggage of email but somewhere you can keep check on a list of bugs you
have an interest in, personally I make a meta bug and block it with bugs I
am interested in (https://bugzilla.mozilla.org/show_bug.cgi?id=965185) but
I could see "vote" being re purposed as favourite very easily

On 10 June 2015 at 00:06, Dave Camp  wrote:

> We don't use bugzilla votes as a strong signal for prioritization on
> devtools.
>
> We do actually keep an eye on votes in some other channels (
> ffdevtools.uservoice.com), but I don't think anyone on devtools would
> object strongly to votes going away in bugzilla.
>
> -dave
>
>
> On Tue, Jun 9, 2015 at 3:48 PM, Axel Hecht  wrote:
>
> > I recall that at least one group actively uses votes to prioritize stuff.
> >
> > I can't really tell which one, I'm leaning towards devtools, but I don't
> > have any data to back that up.
> >
> > I mostly remember because I was surprised.
> >
> > Also, for a component like devtools, I can see how it'd make sense.
> >
> > Axel
> >
> >
> > On 6/10/15 12:09 AM, Mark Côté wrote:
> >
> >> In a quest to simplify both the interface and the maintenance of
> >> bugzilla.mozilla.org, we're looking for features that are of
> >> questionable value to see if we can get rid of them.  As I'm sure
> >> everyone knows, Bugzilla grew organically, without much of a road map,
> >> over a long time, and it experienced a lot of scope bloat, which has
> >> made it complex both on the inside and out.  I'd like to cut that down
> >> at least a bit if I can.
> >>
> >> To that end, I'd like to consider the voting feature.  While it is
> >> enabled on a quite a few products, anecdotally I have heard
> >> many times that it isn't actually useful, that is, votes aren't really
> >> being used to prioritize features & fixes.  If your team uses voting,
> >> I'd like to talk about your use case and see if, in general, it makes
> >> sense to continue to support this feature.
> >>
> >> Thanks,
> >> Mark
> >>
> >>
> > ___
> > 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

Intent to ship: Autodiscovery of WebExtension search engines

[Dale Harvey]

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: 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
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

[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
> <https://www.iana.org/assignments/media-types/media-types.xhtml> 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]

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