How can I distribute my xulrunner app with flash plugin?
I don't want to rely on user having flash installed, instead my app that makes
use of xulrunner should have the flash plugin.
I tried to create a plugins directory under xulrunner and to put there the
NPSWF32.dll but it doesn't detect it.
On Tue, Feb 12, 2013 at 8:29 PM, Asa Dotzler wrote:
>
> My point isn't to quarrel about the depth of that back stack, but to say
> that it is not OK to simply dismiss a new feature because it increases
> memory footprint. Features vs footprint is a balancing act. Both sides must
> be weighed and t
On Thu, Feb 14, 2013 at 3:21 AM, Benjamin Smedberg wrote:
> On what OSes? Windows by default coalesces mouse move events. They are
> like WM_PAINT events in that they are only delivered when the event queue
> is empty. See
> http://blogs.msdn.com/b/oldnewthing/archive/2011/12/19/10249000.aspx
>
>
On 2/13/13 7:36 PM, Simon Kornblith wrote:
Don't workers have access to XMLHttpRequest?
That's implemented by sending messages to the main thread and doing the
XHR from there, so no messages means no XHR.
-Boris
___
dev-platform mailing list
dev-p
On Feb 13, 5:25 pm, Benjamin Smedberg wrote:
> On 2/13/2013 4:28 PM, Kyle Huey wrote:
>
>
>
>
>
>
>
> > On Wed, Feb 13, 2013 at 9:20 PM, Benjamin Smedberg
> > wrote:
>
> >> On 2/13/2013 1:39 PM, Kyle Huey wrote:
>
> >>> On Wed, Feb 13, 2013 at 6:35 PM, Brian Smith wrote:
>
> >>> At what point
On 2/13/2013 4:28 PM, Kyle Huey wrote:
On Wed, Feb 13, 2013 at 9:20 PM, Benjamin Smedberg wrote:
On 2/13/2013 1:39 PM, Kyle Huey wrote:
On Wed, Feb 13, 2013 at 6:35 PM, Brian Smith wrote:
At what point during XPCOM shutdown are workers destroyed?
xpcom-shutdown-threads
What workers ar
On Wed, Feb 13, 2013 at 9:20 PM, Benjamin Smedberg wrote:
> On 2/13/2013 1:39 PM, Kyle Huey wrote:
>
>> On Wed, Feb 13, 2013 at 6:35 PM, Brian Smith wrote:
>>
>> At what point during XPCOM shutdown are workers destroyed?
>>>
>>> xpcom-shutdown-threads
>>
> What workers are these? Do workers out
On 2/13/2013 1:39 PM, Kyle Huey wrote:
On Wed, Feb 13, 2013 at 6:35 PM, Brian Smith wrote:
At what point during XPCOM shutdown are workers destroyed?
xpcom-shutdown-threads
What workers are these? Do workers outlast the page that loaded them?
The entire DOM should be torn down at or before
Kyle Huey wrote:
> Brian Smith < bsm...@mozilla.com > wrote:
>
> At what point during XPCOM shutdown are workers destroyed?
>
> xpcom-shutdown-threads
NSS gets shut down way before then, because it can write to the profile. Same
with Necko.
Cheers,
Brian
___
On Wed, Feb 13, 2013 at 6:35 PM, Brian Smith wrote:
> At what point during XPCOM shutdown are workers destroyed?
>
xpcom-shutdown-threads
- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platfo
I've completed all the testing that I can think of to alert of us any concerns
and found no regressions in the latest Nightly builds. See my comment here:
https://bugzilla.mozilla.org/show_bug.cgi?id=827354#c26
Please advise if anything more is needed.
Anthony Hughes
QA Engineer, Desktop Firefox
Benjamin Smedberg wrote:
I do wonder if WM_MOUSEMOVE has priority over WM_PAINT so that if the
mouse is moving a lot, that could affect the latency of WM_PAINT.
I think we used to artificially bump keyboard and mouse messages over
posted messages to stop posted messages from affecting the lat
Kyle Huey wrote:
>1. Dealing with the different ownership model on worker threads
>(no cycle collector, all owning references go through JS).
>2. Dealing with things that are not available off the main thread
>(no necko, no gfx APIs, etc).
FWIW, I think the networking team has a go
L. David Baron wrote:
On Tuesday 2013-02-12 20:17 -0800, Stephen Pohl wrote:
L. David Baron wrote:
On Tuesday 2013-02-12 18:40 -0800, Asa Dotzler wrote:
doing something horribly wrong with memory. This is simply a memory-expensive
feature and it's a feature we *must* land.
Why is it s
Gervase Markham wrote:
I'm not enamoured of the idea of the answer to "how do I watch Netflix/LoveFilm in
Firefox?" being "head over to Microsoft and install Silverlight; bad luck if you run
anything other than Windows or Mac OS X".
(AFAICT, that is the answer at the moment anyway, but at lea
That's a good point. The plan is to finish the layers refactoring landing by
the week of March 18th. I didn't realize that anybody was looking at OMT
painting right now. This was identified as something that needs to be done,
together with OMT texture updates, removal of non-OMT code, etc.,
This is kind of OT, but
> OTOH, if the computer has memory available, we should be using *all* of it
> any place we can trade
> memory for speed.
We considered this idea in MemShrink some months ago, and we mostly
dropped it. There are two essential problems that we weren't able to
overcome.
1
On 13/02/13 12:55, Henri Sivonen wrote:
> I don't think we have this option. Microsoft and Google have editors
> on the EME spec. So this option looks more like: Have Hollywood movies
> available with good performance and without additional installs in IE
> and Chrome and *for the time being* avail
On 2/12/2013 10:18 PM, Robert O'Callahan wrote:
Context: bug 837985.
At times we can be flooded by OS-level mousemove events.
On what OSes? Windows by default coalesces mouse move events. They are
like WM_PAINT events in that they are only delivered when the event
queue is empty. See
http://b
On 2/13/2013 3:12 AM, Justin Lebar wrote:
c) Consider adaptive techniques so that users who use this feature
heavily will store more screenshots (at the cost of more memory),
while those who don't use it won't pay a price.
Apart from the other solution of re-rendering directly from bfcache,
this
For starters, see
http://lists.w3.org/Archives/Public/public-html-admin/2013Feb/0178.html
.
On Wed, Feb 13, 2013 at 1:30 PM, Gervase Markham wrote:
> A) Provide a DRM mechanism in HTML5 which keeps them happy. (How
> breakable or not it actually is, is a different question.) Have the
> video deli
On 12/02/13 21:20, Benoit Jacob wrote:
> I agree wholeheartedly with Benjamin and care about this, but I don't have
> a lot of time to get into this presumably time-consuming discussion on a
> W3C mailing list --- so I'd just like to express support to any Mozilla
> representative fighting this fig
On 12/02/13 21:20, Benoit Jacob wrote:
> I agree wholeheartedly with Benjamin and care about this, but I don't have
> a lot of time to get into this presumably time-consuming discussion on a
> W3C mailing list --- so I'd just like to express support to any Mozilla
> representative fighting this fig
On 12 February 2013 21:57:53, Clint Talbert wrote:
I agree in part with the assertion about testing - that the existing
reftests will catch most regressions stemming from this. But I think
we also need some measurements around scrolling/responsiveness in
order to verify that off main thread paint
Now that I've looked more closely, I take back my earlier "What Ed
said." The issue is more nuanced than I originally thought.
> To save everyone having to look at the graph - the initial landing showed a
> consistent 20% regression in trace malloc maxheap. If this were a 1-5%
> regression, then
25 matches
Mail list logo