I think you want the "screen" topic, and the "locked-foreground" state
to denote when to disable the screen saver.
HTMLMediaElement should already manage only disabling the screen saver
when media is playing and in a foreground tab, and bug 1022669 is being
worked on right now to ensure that we do
We want to inhibit the screensaver when video is playing, not when
*fullscreen* video is playing. It looks like the patch above is trying
to only inhibit the screensaver for fullscreen video.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed t
Because opinions differ. ;)
We also want non-fullscreen video and webrtc chats to disable the
screensaver. I, for one, find it very annoying when I'm watching a non-
fullscreen video and the screensaver kicks in.
FYI, there's code in HTMLMediaElement to ensure the screensaver is only
disabled whe
Comment on attachment 8401684
Implement WakeLockListener on Linux to disable screensaver while video is
playing
Review of attachment 8401684:
-
This is the behaviour we want (locking video irrespective of whether
we're fullscreen or
(In reply to Lawrence Mandel [:lmandel] from comment #40)
> I discussed this issue with the desktop team (Chad, Madhava, Gavin). This is
> not a high priority for them right now. As such, dropping the tracking flag.
>
> From comment 36 I take it that this has already been fixed on Windows in
> ano
The fix for this will ship on Windows in Firefox 30. Other platforms
hopefully will make by Firefox 30 or soon after.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/434476
Title:
scre
We already use the power manager service to create a "screen" wake lock
to disable the screen saver in HTMLVideoElement::WakeLockUpdate(), but
the wake lock listener that actually disables the screen saver is only
implemented for B2G and I think Android, but not on other platforms.
I have a patch
(In reply to :Ehsan Akhgari (needinfo? me!) (slow responsiveness,
emailacopolypse) from comment #32)
> Can we at least do that for videos which have started playback as a result
> of a user action?
Sure, that sounds like a good idea. Reasonable even.
We may need to wait for bug 966493 to be fixe
(In reply to :Ehsan Akhgari (needinfo? me!) (slow responsiveness,
emailacopolypse) from comment #29)
> (In reply to comment #28)
> > We should disable the screen save for non-fullscreen playback too.
>
> Why? Some websites use as an element in their design these days
> (for example, as the page
We should disable the screen save for non-fullscreen playback too.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/434476
Title:
screensaver starts while playing HTML5 videos
Status i
Comment on attachment 765205
Better error message
Review of attachment 765205:
-
A build peer should review this.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in
Excellent, thanks Ralph.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1051559
Title:
Build Firefox with GStreamer support
Status in The Mozilla Firefox Browser:
Confirmed
Status
Comment on attachment 763014
Enable gstreamer by default, preffed off
Review of attachment 763014:
-
r=cpearce for the changes other than those in configure.in. I'll leave
that to khuey.
::: configure.in
@@ +5754,5 @@
> dnl ===
(In reply to Alessandro Decina from comment #55)
> Created attachment 727111
> gst codec whitelist
>
> This patch makes the gst backend stop in ReadMetadata if the stream being
> decoded includes unsupported codecs. I'm not sure it's stopping in the right
> place, it makes playing
> http://www.too
Comment on attachment 727111
gst codec whitelist
That looks fine, it behaves as expected and stops playback of the 3GPP
container in particular.
Mochitests timeout in test_buffered for me now though, and the fix I
suggested of clamping the buffered ranges at duration didn't seem to fix
the test_b
(In reply to Alessandro Decina from comment #56)
> (In reply to Chris Pearce (:cpearce) from comment #54)
> > I built latest trunk on my Fedora box this morning with --enable-gstreamer,
> > and I still get the following test failure in
> > content/media/test/test_buffered.html:
> >
> > TEST-UNEXPE
I built latest trunk on my Fedora box this morning with --enable-
gstreamer, and I still get the following test failure in
content/media/test/test_buffered.html:
TEST-UNEXPECTED-FAIL| unknown test url | owl.mp3: First range end should
be media end - got 3.368, expected 3.3698
(In reply to Henri
You can already set the pref "media.prefer-gstreamer" to true if you
want to play WebM and Ogg with GStreamer in Firefox.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1051559
Title:
(In reply to Alessandro Decina from comment #46)
> In addition to that, we could potentially consider importing the
> ogg/webm/h264 gst plugins in m-c so there's even more control over those.
I'd rather keep our existing backends/libraries for decoding Ogg and
WebM unless there's a compelling reas
(In reply to Chris Pearce (:cpearce) from comment #31)
> > > One of the reasons I am interested in this bug is due to what seems to be
> > > much better video acceleration code in gStreamer vs Firefox. At least
> > > could
> > > it be be made an about:config option, pass all to gstreamer?
> >
>
(In reply to Bryan Quigley from comment #24)
> (In reply to Chris Pearce (:cpearce) from comment #19)
> > We talked about this in Auckland, and we'd prefer to use our existing
> > built-in backends for Ogg and WebM, since they've been fuzz tested and we
> > know they're reliable.
>
> Maybe I'm mis
(In reply to Chris Pearce (:cpearce) from comment #27)
> This decision also motivated by the fact that we know our built in decoders
> work reliably, and we know that the GStreamer backend has some problems; it
> fails our unit tests, so we know there are bugs either in GStreamer or in
> our use of
We talked about this in Auckland, and we'd prefer to use our existing
built-in backends for Ogg and WebM, since they've been fuzz tested and
we know they're reliable.
I'm going to change our decoder creation code in bug 799344 to not use
GStreamer for Ogg and WebM.
(And my GStreamer is whatever i
Created attachment 670672
GStreamer backend mochitest failures (with GStreamer only playing H.264, not
Ogg or WebM)
Additionally, the mochitests fail with the GStreamer backend enabled.
Currently the GStreamer backend takes over playback of Ogg and WebM
resources when it's enabled, and Firefox ti
(In reply to Sid from comment #298)
> Just in case, SDK is out.
> http://gstreamer.com/
In the Windows installation instructions they recommend removing the
client app's dependency on MSVC2010's runtime DLL and using the "“basic”
C runtime which comes in every Windows system since Windows XP, and
25 matches
Mail list logo