Re: Removing the Battery Status API?

[mail]

Here's a real world use case:
https://github.com/jpdevries/mab-recommendations/blob/low-battery/proposed/low-battery.md#-responding-to-battery-levels

An interface whose components reduce their CPU usage based on battery levels. 
When the battery is low maybe they lower their frame rate, hit the API less 
often, don't use animation. 

I understand the privacy concerns, but why can't these be handled similar to 
the Geolocation API? Ask permission to use / user opts in.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Terminating xulrunner?

[Mike Hoye]

On 2016-11-28 9:32 PM, edunl...@gmail.com wrote:

My Firefox Thunderbird will not open correctly because it wants XUL Runner to 
be 45.5.0.  Can you help me?


Unfortunately, XULRunner hasn't been under active development since 
mid-2015, and was never officially supported.


I suggest downloading and reinstalling the most recent version of 
Thunderbird, available here:


https://www.mozilla.org/en-US/thunderbird/

This may resolve your issue. You can email me directly if it doesn't, 
and I'll see if I can direct you to the right people in the Thunderbird 
community.


- mhoye



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

Re: Terminating xulrunner?

[edunlap2]

On Sunday, January 12, 2014 at 7:34:54 PM UTC-5, Mike Hommey wrote:
> Hi,
> 
> Let's face it: xulrunner is hardly maintained, we barely build and test
> it on automation, and the result is that it is often broken for long
> periods of time.
> 
> I propose that we just stop pretending, and terminate xulrunner,
> considering the following:
> - Xulrunner is lagging behind Firefox: DLL block list, startup telemetry,
>   etc.
> - Since bug 755724, running firefox -app application.ini is 99% the same
>   as running xulrunner application.ini, except for a few details that
>   should be considered bugs. Before that bug, it was quite different,
>   as browser-specific files were available to the xul application.
> - There is no reason we can't generate the sdk from firefox instead of
>   xulrunner. Moreover that would make firefox-specific interfaces
>   available in the sdk that aren't currently (which may or may not be a
>   good thing, arguably)
> - We could include the xulrunner and xulrunner-stub executables as part
>   of firefox. xulrunner-stub is small and self-contained, and xulrunner
>   could be replaced by something that calls firefox -app. Or we could
>   make the firefox executable check under what name it's called and act
>   accordingly.
> 
> Thoughts?
> 
> Mike

My Firefox Thunderbird needs XUL Runner to be 45.5.0 or it won't let me see my 
incoming emails.  Can you help me?
edunlap
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Terminating xulrunner?

[edunlap2]

On Sunday, January 12, 2014 at 7:34:54 PM UTC-5, Mike Hommey wrote:
> Hi,
> 
> Let's face it: xulrunner is hardly maintained, we barely build and test
> it on automation, and the result is that it is often broken for long
> periods of time.
> 
> I propose that we just stop pretending, and terminate xulrunner,
> considering the following:
> - Xulrunner is lagging behind Firefox: DLL block list, startup telemetry,
>   etc.
> - Since bug 755724, running firefox -app application.ini is 99% the same
>   as running xulrunner application.ini, except for a few details that
>   should be considered bugs. Before that bug, it was quite different,
>   as browser-specific files were available to the xul application.
> - There is no reason we can't generate the sdk from firefox instead of
>   xulrunner. Moreover that would make firefox-specific interfaces
>   available in the sdk that aren't currently (which may or may not be a
>   good thing, arguably)
> - We could include the xulrunner and xulrunner-stub executables as part
>   of firefox. xulrunner-stub is small and self-contained, and xulrunner
>   could be replaced by something that calls firefox -app. Or we could
>   make the firefox executable check under what name it's called and act
>   accordingly.
> 
> Thoughts?
> 
> Mike
My Firefox Thunderbird will not open correctly because it wants XUL Runner to 
be 45.5.0.  Can you help me?  edunlap

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

Re: Rust required to build Gecko

[Mike Hommey]

On Mon, Nov 28, 2016 at 12:01:45PM -0800, Gerald Squelart wrote:
> On Tuesday, November 29, 2016 at 5:03:17 AM UTC+11, Gregory Szorc wrote:
> > > On Nov 27, 2016, at 14:46, Gerald Squelart  wrote:
> > >
> > >> On Saturday, November 26, 2016 at 3:59:05 AM UTC+11, Ralph Giles wrote:
> > >> On Fri, Nov 25, 2016 at 7:48 AM, Andrew Halberstadt
> > >>  wrote:
> > >>
> > >>> For anyone confused by this, the binaries are downloaded to ~/.cargo/bin
> > >>> and adding this directory to your $PATH should fix the issue. The
> > >>> bootstrapper explains this if you run it a second time, but makes no
> > >>> mention of it the first time through for some reason.
> > >>
> > >> Thanks. I've tried to address this in
> > >> https://bugzilla.mozilla.org/show_bug.cgi?id=1319860
> > >>
> > >> -r
> > >
> > > Hi Ralph,
> > >
> > > Following your instructions, rustc and friends are in ~/.cargo/bin, and 
> > > I've added that path in my $PATH.
> > >
> > > But now, `./mach build` gives me:
> > >  force-cargo-build
> > >  env: /usr/local/bin/cargo: No such file or directory
> > >  /mozilla-central/config/rules.mk:951: recipe for target 
> > > 'force-cargo-build' failed
> > >  gmake[2]: *** [force-cargo-build] Error 127
> > >  /mozilla-central/config/recurse.mk:71: recipe for target 
> > > 'toolkit/library/rust/target' failed
> > >  gmake[1]: *** [toolkit/library/rust/target] Error 2
> > >  gmake[1]: *** Waiting for unfinished jobs
> > >
> > > Sym-linking rustc from /usr/local/bin worked, but it feels wrong!
> > 
> > This is a longstanding problem with the build system w.r.t. detected
> > programs changing out from under the build system: the build system
> > makes a lot of assumptions that the system doesn't change between
> > builds. If you do things like change the toolchain or where binaries
> > are installed, you'll need to perform a clobber build.
> 
> Ah yes, it worked after a clobber. Sorry, I should have tried that before.

Note, you probably didn't /actually/ need a clobber. It would probably
have fixed itself after re-running mach configure.

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

Re: Rust required to build Gecko

[Michael Froman]

See inline.

> On Nov 28, 2016, at 11:37 AM, Ralph Giles  wrote:
> 
> On Mon, Nov 28, 2016 at 9:28 AM, Michael Froman  wrote:
> 
>> Any thoughts?  Further info:
>> mfroman-23602:moz-central mfroman$ which rustc
>> /Users/mfroman/.cargo/bin/rustc
>> mfroman-23602:moz-central mfroman$ rustc --version
>> error: no default toolchain configured
> 
> Very mysterious. This error message usually means rustup's redirect to
> the actual toolchain (in /Users/mfroman/.multirust/toolchains) is
> confused. I've seen it when the executable filename has a prefix, for
> example.
> 
> Make sure there's a toolchain installed under ~/.multirust, then maybe
> try `rustup update` and see what that says.
mfroman-23602:moz-central mfroman$ rustup update
info: no updatable toolchains installed
info: checking for self-updates

> 
> If that doesn't work, try `rustup default stable`.
mfroman-23602:moz-central mfroman$ rustup default stable
info: syncing channel updates for 'stable-x86_64-apple-darwin'
info: downloading component 'rustc'
 28.7 MiB /  28.7 MiB (100 %)   1.4 MiB/s ETA:   0 s
info: downloading component 'rust-std'
 36.1 MiB /  36.1 MiB (100 %)   1.4 MiB/s ETA:   0 s
info: downloading component 'rust-docs'
  7.5 MiB /   7.5 MiB (100 %)   1.4 MiB/s ETA:   0 s
info: downloading component 'cargo'
  2.4 MiB /   2.4 MiB (100 %)   1.5 MiB/s ETA:   0 s
info: installing component 'rustc'
info: installing component 'rust-std'
info: installing component 'rust-docs'
info: installing component 'cargo'
info: default toolchain set to 'stable-x86_64-apple-darwin'

  stable-x86_64-apple-darwin installed - rustc 1.13.0 (2c6933acc 2016-11-07)


> 
> -r

Now, I’ve made it through the bootstrap successfully.  Thanks for the tips!  
I’m not sure exactly what happened the first time.  Possibly a network failure 
during the original download or something.

-Michael.



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

Re: Rust required to build Gecko

[Gerald Squelart]

On Tuesday, November 29, 2016 at 5:03:17 AM UTC+11, Gregory Szorc wrote:
> > On Nov 27, 2016, at 14:46, Gerald Squelart  wrote:
> >
> >> On Saturday, November 26, 2016 at 3:59:05 AM UTC+11, Ralph Giles wrote:
> >> On Fri, Nov 25, 2016 at 7:48 AM, Andrew Halberstadt
> >>  wrote:
> >>
> >>> For anyone confused by this, the binaries are downloaded to ~/.cargo/bin
> >>> and adding this directory to your $PATH should fix the issue. The
> >>> bootstrapper explains this if you run it a second time, but makes no
> >>> mention of it the first time through for some reason.
> >>
> >> Thanks. I've tried to address this in
> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1319860
> >>
> >> -r
> >
> > Hi Ralph,
> >
> > Following your instructions, rustc and friends are in ~/.cargo/bin, and 
> > I've added that path in my $PATH.
> >
> > But now, `./mach build` gives me:
> >  force-cargo-build
> >  env: /usr/local/bin/cargo: No such file or directory
> >  /mozilla-central/config/rules.mk:951: recipe for target 
> > 'force-cargo-build' failed
> >  gmake[2]: *** [force-cargo-build] Error 127
> >  /mozilla-central/config/recurse.mk:71: recipe for target 
> > 'toolkit/library/rust/target' failed
> >  gmake[1]: *** [toolkit/library/rust/target] Error 2
> >  gmake[1]: *** Waiting for unfinished jobs
> >
> > Sym-linking rustc from /usr/local/bin worked, but it feels wrong!
> 
> This is a longstanding problem with the build system w.r.t. detected
> programs changing out from under the build system: the build system
> makes a lot of assumptions that the system doesn't change between
> builds. If you do things like change the toolchain or where binaries
> are installed, you'll need to perform a clobber build.

Ah yes, it worked after a clobber. Sorry, I should have tried that before.

> I just filed bug 1320728 to improve the build system's handling of
> this scenario.

Thank you!
g.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Rust required to build Gecko

[Gregory Szorc]

> On Nov 27, 2016, at 14:46, Gerald Squelart  wrote:
>
>> On Saturday, November 26, 2016 at 3:59:05 AM UTC+11, Ralph Giles wrote:
>> On Fri, Nov 25, 2016 at 7:48 AM, Andrew Halberstadt
>>  wrote:
>>
>>> For anyone confused by this, the binaries are downloaded to ~/.cargo/bin
>>> and adding this directory to your $PATH should fix the issue. The
>>> bootstrapper explains this if you run it a second time, but makes no
>>> mention of it the first time through for some reason.
>>
>> Thanks. I've tried to address this in
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1319860
>>
>> -r
>
> Hi Ralph,
>
> Following your instructions, rustc and friends are in ~/.cargo/bin, and I've 
> added that path in my $PATH.
>
> But now, `./mach build` gives me:
>  force-cargo-build
>  env: /usr/local/bin/cargo: No such file or directory
>  /mozilla-central/config/rules.mk:951: recipe for target 'force-cargo-build' 
> failed
>  gmake[2]: *** [force-cargo-build] Error 127
>  /mozilla-central/config/recurse.mk:71: recipe for target 
> 'toolkit/library/rust/target' failed
>  gmake[1]: *** [toolkit/library/rust/target] Error 2
>  gmake[1]: *** Waiting for unfinished jobs
>
> Sym-linking rustc from /usr/local/bin worked, but it feels wrong!

This is a longstanding problem with the build system w.r.t. detected
programs changing out from under the build system: the build system
makes a lot of assumptions that the system doesn't change between
builds. If you do things like change the toolchain or where binaries
are installed, you'll need to perform a clobber build.

I just filed bug 1320728 to improve the build system's handling of
this scenario.

>
>
> After that, building works, but shows some scary bold text:
>  note: link against the following native artifacts when linking against this 
> static library
>  note: the order and any duplication can be significant on some platforms, 
> and so may need to be preserved
>  note: library: System
>  note: library: c
>  note: library: m
>
> What's with that?
>
> Cheers,
> g.
> ___
> 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: Rust required to build Gecko

[Ralph Giles]

On Mon, Nov 28, 2016 at 9:28 AM, Michael Froman  wrote:

> Any thoughts?  Further info:
> mfroman-23602:moz-central mfroman$ which rustc
> /Users/mfroman/.cargo/bin/rustc
> mfroman-23602:moz-central mfroman$ rustc --version
> error: no default toolchain configured

Very mysterious. This error message usually means rustup's redirect to
the actual toolchain (in /Users/mfroman/.multirust/toolchains) is
confused. I've seen it when the executable filename has a prefix, for
example.

Make sure there's a toolchain installed under ~/.multirust, then maybe
try `rustup update` and see what that says.

If that doesn't work, try `rustup default stable`.

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

Re: Mozilla's x86 Linux builds now require SSE2

[Jim Blandy]

But, how can we so casually drop support for processors manufactured as
recently as 2003? Wasn't there any discussion of this decision?

Just kidding, I'm glad we can finally put the x87 behind us, and I know
there was *lots* of discussion...


On Sun, Nov 27, 2016 at 1:25 AM, Henri Sivonen  wrote:

> https://bugzilla.mozilla.org/show_bug.cgi?id=1274196 has landed for
> Firefox 53. It makes build for 32-bit x86 Linux made on Mozilla's
> infrastructure require SSE2. It does not change the defaults for
> builds made elsewhere.
>
> This effectively means that x86+SSE2 is tier-1 but x86 potentially
> without SSE2 is in the same tier-3 bucket as other CPU architectures
> that Mozilla doesn't provide builds for but Linux distros do.
>
> Mozilla-made builds that require for 32-bit x86 Linux check for SSE2
> on startup and exit with an error message to stderr if SSE2 is not
> found. Depending on their distribution, the affected users may have
> the recourse of obtaining a build that doesn't require SSE2 from their
> Linux distribution. For the duration of the ESR 52 cycle, the users
> could, alternatively, switch to ESR, but the error message does not
> point this out.
>
> For updates, the capability to report the presence of SSE2 went into
> Firefox 51, so the updater can be smart about showing a tombstone SUMO
> link vs. updating.
>
> Notably, this means that 387 floating-point math is no longer tier-1
> now that all tier-1 x86 platforms require SSE2 and, therefore, can use
> standard-based SSE2 floating-point math instead of legacy 387
> floating-point math. x86 Mac and x86 Android never shipped on non-SSE2
> CPUs, so SSE2 has been part of their baseline since the beginning.
> Mozilla's Windows builds have required SSE2 since Firefox 49. SSE2 is
> also a mandatory part of x86_64.
>
> Since the 32-bit x86 targets that are tier-1 for Rust require SSE2,
> this enables us to use rustc with a tier-1 target configuration in
> Mozilla-made Firefox builds for 32-bit x86 Linux.
>
> --
> Henri Sivonen
> hsivo...@hsivonen.fi
> https://hsivonen.fi/
> ___
> 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: Rust required to build Gecko

[Ralph Giles]

On Sun, Nov 27, 2016 at 2:46 PM, Gerald Squelart  wrote:

> Following your instructions, rustc and friends are in ~/.cargo/bin, and I've 
> added that path in my $PATH.
>
> But now, `./mach build` gives me:
>   force-cargo-build
>   env: /usr/local/bin/cargo: No such file or directory
> [...]
> Sym-linking rustc from /usr/local/bin worked, but it feels wrong!

That does seem wrong. So you have rustc and cargo in ~/.cargo/bin, but
it was looking in /usr/local/bin instead? Was there a
/usr/local/bin/rustc previously? What does `which cargo` print?

> After that, building works, but shows some scary bold text:
>   note: link against the following native artifacts when linking against this 
> static library
>   note: the order and any duplication can be significant on some platforms, 
> and so may need to be preserved
>   note: library: System
>   note: library: c
>   note: library: m
>
> What's with that?

The rust compiler prints this out whenever it generates a static
library, to remind you to link the dependencies into the final target.
We do that (XUL has the same dependencies) but I agree the `note`
output is distracting. I wrote a patch to suppress this by writing it
to a file instead, but didn't get it to an acceptable state to land.
If someone wants to un-bitrot it and add tests, I think that would be
the best way to resolve this.
https://github.com/rust-lang/rust/issues/31471

Thanks for sharing your results,
 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: CSS {background,mask}-repeat-{x/y} properties

[Tommy Kuo]

I think we should only implement the `background-repeat-{x|y}`. Currently, no 
browser engine supports `mask-repeat-{x|y}`. But for `background-repeat-{x|y}`, 
Google Chrome already supports it.

In this comment[1], the usage of these properties is above the deprecation 
threshold (both usage rate > 0.07%). So, Google Chrome won't remove these 
properties. I also found this discussion[2], `background-repeat-{x|y}` are 
approved for level 4 of backgrounds and borders.

Currently, for web compatibility, I think we should implement these properties. 
The current status on other browser engines is following:

**Microsoft Edge**

No support.

**Google Chrome**

It supports keywords `repeat` and `no-repeat`.

The behavior of `background-repeat-x: no-repeat` is repeat the background only 
on y-axis, like `background-repeat: no-repeat repeat`.

The behavior of `background-repeat-y: no-repeat` is repeat the background only 
on x-axis, like `background-repeat: repeat no-repeat`.

The behavior of `background-repeat-x: no-repeat; background-repeat-y: 
no-repeat;` is repeat the background only on x-axis, like `background-repeat: 
no-repeat no-repeat`.

**Apple Safari**

No support.

And there is a site[3] using `background-repeat-x` and `background-repeat-y`. 
We can notice that some images should be no-repeat. And it works on Google 
Chrome not on Mozilla Firefox. I attached the screenshot in attachments.

[1]: https://github.com/w3c/csswg-drafts/issues/116#issuecomment-221668012
[2]: http://lists.w3.org/Archives/Public/www-style/2014Apr/0188.html
[3]: http://ocando.vnz.la/

-- 
Tommy Kuo / Software Engineer
ku...@mozilla.com

Mozilla Taiwan


On November 25, 2016 at 02:31:24, L. David Baron (dba...@dbaron.org) wrote:

On Friday 2016-11-25 02:09 +0800, Chih-Hsuan Kuo wrote:  
> It means the browser engines can use the properties, but these properties 
> don't accept any value. It also means the properties don't work.  
>  
>  
> In Google Chrome, these properties can be auto-completed. And the error shows 
> when we set the value to these properties.  
>  
>  
> In Safari, there is no warning symbol on these properties, and the warning 
> symbol only shows on the value we set.  

So my impression is that you're looking to implement these  
unstandardized properties because of Web compatibility risk.  

If you're analyzing that risk, it doesn't matter what developer  
tools do. What matters is whether the presence of the properties in  
Web content does something that we also need to do if we want the  
content to behave in the same way.  

I can't tell from your comments which other browsers do this.  

-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

[Firefox Desktop] Issues found: November 21st to November 25th

[Florin Mezei]

Hi everyone,


Here's the list of new issues found and filed by the Desktop Release QA Team 
last week, November 21 - November 25 (week 47).

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

Status


1319412  

[WinXP] Skipping forward/backward doesn't work properly on Vimeo.com

Core

Audio/Video: Playback

NO

NOBODY

NEW



AURORA CHANNEL


ID

Summary

Product

Component

Is a regression

Assigned to

Status


1319764  

[Linux] Important graphic glitches on Developer Edition First Run UI tour

Core

Graphics

 

 YES

NOBODY

NEW


NIGHTLY CHANNEL


ID

Summary

Product

Component

Is a regression

Assigned to

Status


1319099  

Navigation menu keeps bouncing on free.fr website

Core

Layout

NO

NOBODY

NEW


1319115  

Forwarding Youtube videos on last.fm makes them stuttering

Core

Audio/Video: Playback

NO

NOBODY

NEW


1319728  

Fx with FPI feature wrongly displays that sign-in on youtube has failed even 
though it did not

Core

DOM: Security

NO

NOBODY

NEW


1319756  

Login on Instagram using facebook social network stuck on Fx with FPI

Core

DOM: Security

NO

NOBODY

NEW


1319761  

Login on pinterest using facebook social network not working on Fx with FPI

Core

DOM: Security

NO

NOBODY

NEW


1319767  

Unable to login on imgur using Google+ on Fx with FPI

Core

DOM: Security

NO

NOBODY

NEW


1319773  

Issues signing in on Soundcloud using Firefox with FPI

Core

DOM: Security

NO

NOBODY

NEW



ESR CHANNEL
none

Regards, 

Florin.

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