Re: Moving from xulrunner to firefox SDK

[Manish]

Hi Myk,

Thanks for the response.

did you find any reference for legal requirements where it say that we can ship 
xulrunner application with its own copy of firefox.

I hope you have notice this too because if we launch the application with .bat 
script using firefox then under the task manager the application reference goes 
as "Firefox". I am not sure if we can do anything with that part also. 

Appreciate any help or advise on this.

manish


On Tuesday, 12 September 2017 01:57:02 UTC+5:30, Myk Melez  wrote:
> > Manish 
> > 2017 September 6 at 05:32
> >
> > Thanks Myk
> >
> > But I am bit confuse here. If we go by this way
> >
> > /path/to/firefox --app /path/to/application.ini.
> >
> > First there may be a possibility that Firefox is not installed and if 
> > it is installed and someone updates the firefox to latest version and 
> > the max ver. defined under application.ini is the older one, then the 
> > application won't start and will through the version mismatch alert.
> Yes, these are all drawbacks to reusing an existing installation of 
> Firefox. In order to do so successfully, you would need to ensure that 
> your users install (and retain) Firefox and keep your application 
> up-to-date with new versions of the browser.
> 
> > Isn't there any method or terms defined where I can ship the firefox 
> > directory in the application folder rather than re-brading it or 
> > should we by default set the max version in application.ini to a 
> > higher value i.e 99 or if you can suggest any other way.
> If you set the maxVersion value in application.ini to an unreleased 
> version of Firefox, such as 99, then you face the risk that your 
> application will break with a new version of Firefox that isn't 
> backward-compatible. A better option would be to test your application 
> with each new version of Firefox and then update its maxVersion value 
> accordingly.
> 
> However, the best option is perhaps to ship your application with its 
> own copy of Firefox, as you've suggested. Technically, it's possible to 
> do so. That's the idea behind the qbrt experiment 
>  that I previously mentioned. I'm 
> unfamiliar with the legal requirements for doing so, however.
> 
> -myk

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

Re: Intent to ship: CSS Shapes Module Level 1 (partial)

[Tantek Çelik]

On Thu, Nov 30, 2017 at 2:15 AM, Ting-Yu Lin  wrote:
> Thank you for all the feedback. I feel the safest plan is to ship the entire
> module at once. It also saves some work to implement two preferences to
> exclude the shape-outside:  value which we don't render in the first
> stage.

Thanks for gathering all the feedback Ting-Yu. I agree with your
conclusion of shipping the entire module at once.


> I'm implementing "shape-outside: ", and will do "shape-margin" after
> that. My gut feeling is that the entire module can be completed before
> Firefox 60, which is a cycle late than the two-stages plan.

When you feel confident (perhaps beyond "gut feeling") that we can
land/ship the entire module in 60, could you send an updated Intent to
Ship for the entire module accordingly?

Thanks much!

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

Re: Intent to remove Ambient Light and Proximity sensor APIs

[Anne van Kesteren]

On Mon, Dec 18, 2017 at 7:36 PM, Gervase Markham  wrote:
> appear.in, which supports both audio and video calling via WebRTC, works
> in Firefox for Android, although performance is not awesome on my Z3C
> Compact.
>
> It does not blank the screen when you place the device to your ear.

There might be more secure ways we can address this use case. E.g.,
having a dedicated signal just for that, perhaps only given if the
user already granted access to the microphone and such.

(And if something does require the full power of the proximity API, we
should first work out how to expose it securely. I'm sure folks can
come up with use cases for running arbitrary code as root too, but
that doesn't mean we can offer it.)


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

Re: Intent to remove Ambient Light and Proximity sensor APIs

[Peter Saint-Andre]

On 12/18/17 11:36 AM, Gervase Markham wrote:
> On 18/12/17 18:25, Tantek Çelik wrote:
>> Do you know of a specific (URL?) mobile-device-capable (which
>> device(s)?) WebRTC-based audio-calling webapp that works today? I
>> would be very interested in testing it out.
> 
> appear.in, which supports both audio and video calling via WebRTC, works
> in Firefox for Android, although performance is not awesome on my Z3C
> Compact.

My old team at talky.io offers both web and mobile WebRTC, too:

https://talky.io/

(For mobile, it's iOS only, not Android.)

Peter




signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to remove Ambient Light and Proximity sensor APIs

[Gervase Markham]

On 18/12/17 18:25, Tantek Çelik wrote:
> Do you know of a specific (URL?) mobile-device-capable (which
> device(s)?) WebRTC-based audio-calling webapp that works today? I
> would be very interested in testing it out.

appear.in, which supports both audio and video calling via WebRTC, works
in Firefox for Android, although performance is not awesome on my Z3C
Compact.

It does not blank the screen when you place the device to your ear.

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

Re: Intent to remove Ambient Light and Proximity sensor APIs

[Tantek Çelik]

On Mon, Dec 18, 2017 at 5:52 AM, Gervase Markham  wrote:
> On 17/12/17 15:29, Jonathan Kingston wrote:
>> I am suggesting the removal of both Ambient Light and Proximity Sensor APIs
>> via a preference so we can ensure there is no adverse impact to the web
>> with a quick mitigation if needed.

I think this removal is prudent and timely. It is consistent with our
default principles on privacy etc. and good to do it quickly while we
think the potential impact is low at worst.


> Is it fair to say that after removal of the Proximity Sensor API, no
> e.g. WebRTC-based audio-calling webapp

Do you know of a specific (URL?) mobile-device-capable (which
device(s)?) WebRTC-based audio-calling webapp that works today? I
would be very interested in testing it out.


> will be able to blank the screen
> when the user holds the device to their ear?
>
> That seems sad.

It's likely worth capturing your use-case in the Sensors Use-cases doc:
* https://w3c.github.io/sensors/usecases

That specific use-case doesn't seem to be in there, so go ahead and
file it here and feel free to cc: @tantek
* https://github.com/w3c/sensors/issues

Thanks,

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

Re: All about Prefs

[Andrea Marchesini]

DOMPreferences was introduced (but it's not landed yet because of some
mochitest failures) to cleanup how preferences are managed by workers.

Preferences getters/setters are main-thread only and, currently, in order
to propagate a white-list of prefs [1], we have to dispatch runnables to
any active workers each time one of them changes.
DOMPreferences uses atomic prefs getters introduced by bug 1417741 to avoid
all of this.

We can continue the discussion of this feature on bugzilla. I'll NI you
there.

[1] https://searchfox.org/mozilla-central/source/dom/workers/WorkerPrefs.h

On Sun, Dec 17, 2017 at 9:38 PM, Nicholas Nethercote  wrote:

> Hi,
>
> I recently became the module owner of Prefs, and there are several peers.
> In the past it was an ill-maintained module, but that is no longer the
> case.
>
> I have been doing a bunch of work to improve Prefs. As part of this I wrote
> a document that describes how they currently work, and some of their
> problems:
> https://docs.google.com/document/d/1V5Wc9bXwfgMG2JOsswvDPVwZl_
> xiaSBxwJXf3fiEaU8/
>
> I am working on a redesign that will fix a lot of the problems. There was a
> meeting about this in Austin. I hope to implement this in Q1 2018.
>
> By chance, I just discovered that a new DOMPreferences class has been
> created in bug 1419771.
> As far as I can tell, it was created and reviewed by DOM peers without any
> input from Prefs peers. Although the changes are all within dom/, it was
> still an unpleasant surprise, because this is an additional thing I'm going
> to have to deal with in my redesign, on top of the existing gfxPrefs and
> MediaPrefs classes.
>
> If you have changes related to Prefs, please let me (or another Prefs peer)
> know about it. Thanks.
>
> Nick
> ___
> 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 remove Ambient Light and Proximity sensor APIs

[Jonathan Kingston]

> Is it fair to say that after removal of the Proximity Sensor API, no
e.g. WebRTC-based audio-calling webapp will be able to blank the screen
when the user holds the device to their ear?

Yes, however this would be the case for all other browsers too.

Given that we are the only browser to implement the event based interface
 for
this I don't think we should block on the loss of this feature.

The next generation of these APIs are going through TAG review where many
of the concerns here are still being addressed:
https://github.com/w3ctag/design-reviews/issues/207


We may be able to reimplement this functionality with the new APIs with far
less granular access and prompted if more granular is needed. There has
also been no real intent from browser makers to ship them despite their
improvements.

Thanks

On Mon, Dec 18, 2017 at 7:52 AM, Gervase Markham  wrote:

> On 17/12/17 15:29, Jonathan Kingston wrote:
> > I am suggesting the removal of both Ambient Light and Proximity Sensor
> APIs
> > via a preference so we can ensure there is no adverse impact to the web
> > with a quick mitigation if needed.
>
> Is it fair to say that after removal of the Proximity Sensor API, no
> e.g. WebRTC-based audio-calling webapp will be able to blank the screen
> when the user holds the device to their ear?
>
> That seems sad.
>
> Gerv
>
> ___
> 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 remove Ambient Light and Proximity sensor APIs

[Gervase Markham]

On 17/12/17 15:29, Jonathan Kingston wrote:
> I am suggesting the removal of both Ambient Light and Proximity Sensor APIs
> via a preference so we can ensure there is no adverse impact to the web
> with a quick mitigation if needed.

Is it fair to say that after removal of the Proximity Sensor API, no
e.g. WebRTC-based audio-calling webapp will be able to blank the screen
when the user holds the device to their ear?

That seems sad.

Gerv

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

Re: All about Prefs

[Gijs Kruitbosch]

On 18/12/2017 03:38, Nicholas Nethercote wrote:

I am working on a redesign that will fix a lot of the problems. There was a
meeting about this in Austin. I hope to implement this in Q1 2018.


Yay!


If you have changes related to Prefs, please let me (or another Prefs peer)
know about it. Thanks.


Not really a change, just a quick note that I filed metabug 
https://bugzilla.mozilla.org/show_bug.cgi?id=1425613 last week, to avoid 
uncached access to prefs from JS, so potentially relevant to your interests.


Thanks for working on prefs!
Gijs
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[Firefox Desktop] Issues found: December 11th to December 15th

[Bogdan Maris]

Hi everyone,

Here's the list of new issues found and filed by the Desktop Release QA Team 
last week, December 11 - December 15  (week 50).

Additional details on the team's priorities last week, as well as the plans for 
the current week are available at:

https://public.etherpad-mozilla.org/p/DesktopManualQAWeeklyStatus 


RELEASE CHANNEL
none

BETA CHANNEL
ID  Summary Product Component   Is a regression Assigned to
1425239  [Win XP]: Attempting to run a stub 
installer does not redirect the user to the correct page (Esr downloading 
suggestions)   Firefox
Installer
NO  NOBODY

NIGHTLY CHANNEL
ID  Summary Product Component   Is a regression Assigned to
1424874  Additional Shockwave Flash information 
disappears when hitting the "Back" button instead of displaying the 
about:addons  - Plugins list   Toolkit Add-ons Manager
YES 

  Dave Townsend 

ESR CHANNEL
none

Regards,
Bogdan (:bogdan_maris)
Desktop Release QA
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform