Re: Should we disable "autoplay" feature of HTMLMediaElement on mobile?

2013-12-09 Thread Robin Berjon 

On 08/12/2013 15:03 , Robert Kaiser wrote:

That said, I think we should think about how we can enable more user
control of such features. If I open media tabs in the background, I
probably don't want them to autoplay at all.


I think that's the key part. Is there any common usage scenario in which 
autoplay on an inactive tab is not a nuisance? Who hasn't reopened 
Firefox with a bunch of tabs loading and then had to scramble through 
them to find which ones were making noise?


I reckon that making autoplay depend on page visibility would be enough 
to remove the need for user control here, so as to keep things simple. 
IMHO the only question is whether that would break content and possibly 
require a spec change. I suspect not for content; on the spec side it 
already says that UAs don't have to support it.


--
Robin Berjon - http://berjon.com/ - @robinberjon
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Should we disable "autoplay" feature of HTMLMediaElement on mobile?

2013-12-09 Thread Gervase Markham 
On 08/12/13 12:28, Tetsuharu OHZEKI wrote:
> On today's web, there are many "interactive" web sites which play
> sounds when open them. 

I suspect this is somewhat dependent on your culture and environment;
it's not a problem on the set of websites I visit :-)

> Some of them are not controlled by users
> because they doesn't not provide any control. 

If a website played music at me with no way to turn it off, I'd probably
leave and never come back...

Personally, also, "it makes it easier for people to hide their porn use
from others" is not an argument which gets much traction with me.

Gerv

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

Re: Should we disable "autoplay" feature of HTMLMediaElement on mobile?

2013-12-09 Thread Panos Astithas 
On Mon, Dec 9, 2013 at 4:48 PM, Gervase Markham  wrote:

> On 08/12/13 12:28, Tetsuharu OHZEKI wrote:
> > On today's web, there are many "interactive" web sites which play
> > sounds when open them.
>
> I suspect this is somewhat dependent on your culture and environment;
> it's not a problem on the set of websites I visit :-)
>
> > Some of them are not controlled by users
> > because they doesn't not provide any control.
>
> If a website played music at me with no way to turn it off, I'd probably
> leave and never come back...
>
> Personally, also, "it makes it easier for people to hide their porn use
> from others" is not an argument which gets much traction with me.
>

I don't know about that use case, but mine involves Spotify and Soundcloud,
which I have pinned as app tabs. Every now and then I will close the
browser before shutting down the laptop, without remembering to pause the
music in one of those tabs. Booting the laptop afterwards in a public place
never fails to annoy some people.

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

Re: Should we disable "autoplay" feature of HTMLMediaElement on mobile?

2013-12-09 Thread Henri Sivonen 
On Sun, Dec 8, 2013 at 11:49 AM, Robert O'Callahan  wrote:
> I think it's important to have an easy way to mute/unmute the browser, but
> disabling autoplay is probably not the right way to address these issues.

A pref to disable autoplay might be, though.

If autoplay is disabled by default, Web authors will take
counter-measures and start playback from JavaScript. However, if
autoplay is honored by default but the user can turn in off as a pref,
it could be that Web authors won't bother to take counter-measures.

Other than that, it might be worthwhile to investigate if there's a
bug that causes various non-YouTube (Brightcove?) video embeds to
autoplay on Android. On multiple occasions, when I've navigated to
TV-affiliated news sites that have had textual news and a clip from
the same organization's TV news, the clip has started to autoplay on
Android. (Sadly, I haven't collected URLs, though I know I should
have.)

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

Re: Should we disable "autoplay" feature of HTMLMediaElement on mobile?

2013-12-09 Thread Benjamin Smedberg 

On 12/8/2013 4:31 AM, Tetsuharu OHZEKI wrote:


I welcome your feedback to polish Firefox for mobile and web.
Note that autoplay is not the most interesting case, because most of the 
top video sites don't actually use it; instead they use a scripted 
.play() call on load.


https://bugzilla.mozilla.org/show_bug.cgi?id=944876 may be relevant: in 
that bug I'm willing to mentor somebody to add a hidden pref for 
additional control over autoplay behavior.


For desktop Firefox, I don't think we'd ever want to disable autoplay 
*by default* in the foreground tab: many people expect their youtube 
video to just start if they click the link. I suspect that, as discussed 
earlier on this thread, it might make a lot of sense to delay starting 
media in a *background* tab (e.g. opened via middle-click). Then we'd 
autoplay when the video comes into the foreground. We could even 
implement a setting where all media pause in a background tab.


Before we decide on new defaults, I think we should do some experiments 
with what we can actually accomplish in bug 944876, hopefully get some 
prototype  extensions out for people to experiment with, and then come 
back and consider what preferences and defaults it actually makes sense 
to expose.


--BDS

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

Re: Should we disable "autoplay" feature of HTMLMediaElement on mobile?

2013-12-09 Thread Mike Hoye 

On 12/8/2013, 4:49 AM, Robert O'Callahan wrote:

Don't these arguments apply to desktop Firefox used at work, in an Internet
cafe, or in a library, as well?
Media is a power hog on mobile, so it's worthwhile to handle it 
differently there.



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

Disabling Windows 7 testing and nightly builds on b2g18 and b2g18-v1.0.0-hd

2013-12-09 Thread Armen Zambrano G. 
Changing the subject to make it more clear.
I will be raising this on the Monday weekly call as well as the
Engineering meeting.

On 13-12-07 03:31 PM, Armen Zambrano G. wrote:
> (Please follow up on mozilla.dev.b2g)
> 
> Adding dev.platform to reach a wider audience.
> 
> I will bring this up at the Engineering meeting on Tuesday in case I
> don't hear anything back by Tuesday.
> 
> cheers,
> Armen
> 
> On 13-12-06 02:50 PM, Armen Zambrano G. wrote:
>> Hi all,
>> Given that we are only doing security fixes on those two branches.
>> Anyone can say if we still need desktop unit tests and nightly builds on
>> those two branches? [1][2]
>> Would running B2G builds/tests and linux32 build/tests be good enough?
>>
>> Those jobs are running on the old Rev3 minis and would be great to get
>> rid of them now rather than wait until March.
>>
>> regards,
>> Armen
>>
>>
>> [1] https://tbpl.mozilla.org/?tree=Mozilla-B2g18
>> [2] https://tbpl.mozilla.org/?tree=Mozilla-B2g18-v1.1.0hd
>>
> 

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

Re: PSA: Shutting down my mozilla git mirror in three weeks

2013-12-09 Thread Ehsan Akhgari 
Gentle reminder that this is happening this Friday.  Ideally you should
have migrated your local git clones to the new repositories by now, but if
you haven't, please take some time to do this before this Friday.

Again, if you have a reason why I should postpone this please speak up!

Cheers,

--
Ehsan



On Mon, Nov 25, 2013 at 7:39 AM, Ehsan Akhgari wrote:

> Dear all,
>
> For the past two and a half years I have been maintaining a git mirror of
> mozilla-central plus a lot of the other branches that people found useful
> at https://github.com/mozilla/mozilla-central.  Over the years this
> proved to be too much work for me to keep up with, and given the existence
> of the new git mirrors that are supported by RelEng, I'm planning to shut
> down the update jobs for this repository on Friday, Dec 13, 2013 and take
> the repository down.
>
> I strongly suggest that if you have been using and relying on this
> repository before, please consider switching to the RelEng repositories as
> soon as possible.  https://github.com/mozilla/gecko-dev is the main
> repository where you can find branches such as trunk/aurora/b2g
> branches/etc and https://github.com/mozilla/gecko-projects is a
> repository which contains project branches and twigs.  (Note that my
> repository hosts all of these branches in a single location, but from now
> on if you use both of these branch subsets you will need to have two
> upstream remotes added in your local git clone.)
>
> The RelEng repositories have a similar history line including the CVS
> history but they have completely different commit SHA1s, so pulling that
> repo into your existing clones is probably not what you want.  If you don't
> have a lot of non-merged branches, your safest bet is cloning from scratch
> and then port your existing branches manually.  If you have a lot of local
> branches, you may want to wait for the script that John Schoenick is
> working on in bug 929338 which will assist you in rebasing those branches
> on top of the new history line.
>
> Last but not least, I really hate to have to disrupt your workflow like
> this.  I do hope that three weeks is enough advance notice for everybody to
> successfully switch over to the new mirrors, but if you have a reason for
> me to delay this please let me know and I will do my best to accommodate.
>
> Cheers,
> --
> Ehsan
> 
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

DLLs with missing symbols that make crash signatures less useful

2013-12-09 Thread Benjamin Smedberg 
With some recent improvements in crash-stats data[1], we now have the 
ability to report on which crashes don't have the necessary symbols to 
produce a useful crash signature. I have generated the following reports 
from yesterday's crash data:


https://crash-analysis.mozilla.com/bsmedberg/missing-symbols.20131208.byname.csv
https://crash-analysis.mozilla.com/bsmedberg/missing-symbols.20131208.csv

The "byname" report just looks at which DLL names are missing. The other 
reports specifically on which DLL versions are missing.


Summary:

* The out-of-memory issue is causing us not to record symbol information 
for xul.dll in Firefox 25. This was fixed in Firefox 26[2]
* by a large margin graphics drivers are the big problem: Nvidia 
(nvwgf2um.dll/nvumdshim.dll/nvapi.dll/nvd3dum.dll), Intel 
(igdumd32.dll/igd10umd32.dll/igd10iumd32.dll) and ATI/AMD 
(atidxx32.dll/atiumdag.dll).
* We are missing some Windows symbols (user32.dll/mf.dll and a few 
others). These are usually available from the Microsoft symbol server, 
so I will follow up on this to figure out why they aren't working correctly.

* Some probably-malware is showing up: sdata.dll
* Some 3rd-party software of dubious quality is showing up: radhslib.dll 
is Naomi Internet Filter, bug 725503. gbmzh_uni.dll is bug 838568.

* Java is npjp2.dll and jvm.dll
... and there's a very long tail

Overall, I don't think there is much immediate action we can take to 
make this better. Long-term, we should continue working with partners 
such as graphics card vendors to get encrypted symbols for the user-mode 
drivers. 
https://developer.mozilla.org/en-US/docs/Crash_Reporting_Guide_for_Firefox_OS_Partners#Upload_Symbols_to_Mozilla 
has some details about how they can provide Mozilla with encrypted 
symbols that would improve stackwalking and crash signature analysis.


--BDS

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

Re: Should we disable "autoplay" feature of HTMLMediaElement on mobile?

2013-12-09 Thread Chris Pearce 

On 12/10/2013 4:38 AM, Henri Sivonen wrote:

On Sun, Dec 8, 2013 at 11:49 AM, Robert O'Callahan  wrote:

I think it's important to have an easy way to mute/unmute the browser, but
disabling autoplay is probably not the right way to address these issues.

A pref to disable autoplay might be, though.


We have this, set media.autoplay.enabled to false.

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

mozmake users, upgrade

2013-12-09 Thread Mike Hommey 
Hi,

It seems a lot of people are using mozmake, which is good,
unfortunately, some are using an old version and i broke them with bug
944569. Those people need to upgrade mozmake by taking the last version
on either http://people.mozilla.org/~mhommey/mozmake.exe or
https://hg.mozilla.org/projects/birch/file/tip/mozmake.exe.
Alternatively, they can upgrade mozilla build to the pre-release of 1.9.0
that RyanVM posted a few days ago.

Cheers,

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

Re: Should we disable "autoplay" feature of HTMLMediaElement on mobile?

2013-12-09 Thread Reuben Morais 
On Dec 9, 2013, at 19:17, Chris Pearce  wrote:
> On 12/10/2013 4:38 AM, Henri Sivonen wrote:
>> On Sun, Dec 8, 2013 at 11:49 AM, Robert O'Callahan  
>> wrote:
>>> I think it's important to have an easy way to mute/unmute the browser, but
>>> disabling autoplay is probably not the right way to address these issues.
>> A pref to disable autoplay might be, though.
> 
> We have this, set media.autoplay.enabled to false.

Note that B2G doesn't have an about:config.

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

Re: Should we disable "autoplay" feature of HTMLMediaElement on mobile?

2013-12-09 Thread Tetsuharu OHZEKI 
2013/12/10 Reuben Morais :
> Note that B2G doesn't have an about:config.

We can resolve with to add an option to gaia UI.

-- 
Tetsuharu OHZEKI
saneyuki.s.s...@gmail.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Should we disable "autoplay" feature of HTMLMediaElement on mobile?

2013-12-09 Thread Tetsuharu OHZEKI 
2013/12/10 Benjamin Smedberg :
> https://bugzilla.mozilla.org/show_bug.cgi?id=944876 may be relevant: in that
> bug I'm willing to mentor somebody to add a hidden pref for additional
> control over autoplay behavior.

Sounds good. I feel this approach is more smart like roc said.


> For desktop Firefox, I don't think we'd ever want to disable autoplay *by
> default* in the foreground tab: many people expect their youtube video to
> just start if they click the link. I suspect that, as discussed earlier on
> this thread, it might make a lot of sense to delay starting media in a
> *background* tab (e.g. opened via middle-click). Then we'd autoplay when the
> video comes into the foreground. We could even implement a setting where all
> media pause in a background tab.

I almost agree. For desktop Firefox, we should not (cannot) change the
default behavior for autoplay. This is (historical) protocol. Even if
we provide other click-to-plays options, we might not change the
default.

However, for desktop, I don't think it's good that providing as
default to delay starting in background tabs. This is same with that
many people expect their youtube video to just start if they click the
link. Some of them also expect their youtube video start in background
tabs as podcast.

For mobile, this delaying approach is well for saving power. I feel
this approach make sense.

-- 
Tetsuharu OHZEKI
saneyuki.s.s...@gmail.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform