GECKO 14: How to get thread safe object of nsIWebProgress

2012-07-30 Thread salilak 
Hi 
dev environment: Windows and VS, win32[c++]
Background: I have a callback function which loads the url using 
nsIWebNavigation object. This call back function is called through some RPC. 
Current process of getting nsIWebNavigation object:
1. In method "OnStateChange", created nsIProxyObjectManager object using 
nsIServiceManager object.
2. called GetProxyForObject of nsIProxyObjectManager , to get thread safe 
nsIWebProgress object instance from the input parameter object onStateChange. 
3. called do_QueryInterface function to get nsIWebNavigation object from thread 
safe nsIWebProgress object and saved "nsIWebNavigation " object in a static 
variable 
4. Now Using nsIWebNavigation object, in the callback function [ which is 
called by a RPC, asynchronously ], load a specific URI using LoadURI.

But now nsIProxyObjectManager is obsolete and I am not sure how to get a thread 
safe object to nsIWebNavigation from nsIWebProgress[ which is passed to 
"onStateChange" function.

I have gone through the document 
"https://developer.mozilla.org/en/XPCOM/Making_cross-thread_calls_using_runnables";,
 which tells about how to run a method asynchronously. I hove no issue in 
calling the a method asynchronously. I have problem in sharing the object 
between main thread and callback [nsIWebNavigation object]

Any help on this is appreciated.

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

Re: Extending with new image format

2012-07-30 Thread Yury Delendik 

On 7/27/2012 4:36 PM, Zack Weinberg wrote:


On the other hand, enabling people to experiment with new image formats
via carefully sandboxed JavaScript decoders could be very valuable for
the future evolution of the platform.


The JPEG2000 and JBIG2 JavaScript decoders are part of the PDF.js 
project: https://github.com/mozilla/pdf.js/blob/master/src/jpx.js and 
https://github.com/mozilla/pdf.js/blob/master/src/jbig2.js

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

Re: Switching nsnull to nullptr

2012-07-30 Thread Ehsan Akhgari 

On 12-07-30 10:23 AM, Aryeh Gregor wrote:

On Wednesday, July 25, 2012 12:45:52 PM UTC+3, Aryeh Gregor wrote:

The C++11 standard defines a new dedicated null-pointer symbol, "nullptr".  It provides better type-safety than 
existing null-pointer definitions, because it doesn't allow implicit conversion to numeric types.  In 
 I defined "nullptr" to mean 0L/0LL (like current 
nsnull) where unsupported, then redefined "nsnull" to mean "nullptr".  This caught a bunch of places 
where people were using nsnull to mean crazy things like NS_OK or other things that happened to equal 0.



The next step is to s/nsnull/nullptr/ in the codebase, and get rid of nsnull.  There's no reason 
for us to use our own identifier when there's a standard one.  This will be of comparable scale to 
the PRBool elimination of last year -- around 20,000 lines changed instead of 30,000.  This will of 
course insta-bitrot any patches that people have that mention "nsnull" anywhere, but a 
shell script will be provided to auto-fix them, as with the PRBool switch (something like "sed 
-i s/\bnsnull\b/nullptr/ .hg/patches{,-*}/*" should do it).



This message is of general interest because after the switch, "nsnull" will no 
longer work, and patch queues will have to be updated.  Also, anyone who maintains a 
branch will want to figure out how to avoid merge pain.


This is now done on m-c:

http://hg.mozilla.org/mozilla-central/rev/b5c4b792f3f2

Ehsan is going to watch the tree and handle the m-i merge.  To un-bitrot your 
Mercurial patches, you can use the script provided here:


Looks like the builds are fairly green on all platforms on both 
mozilla-central and mozilla-inbound.


Please use nullptr in all new code.  We will remove nsnull shortly after 
this, to give people a little time to adjust to using nullptr.


Cheers,
Ehsan

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

Re: Mac OS X 10.5 Support Plans (Updated)

2012-07-30 Thread Hubert Figuière 
On 30/07/12 01:29 AM, Mike Hommey wrote:
> There are two things for which 32-bit is required: 32-bits-only Mac
> (they exist, and they run 10.6 just fine ; not sure about 10.7), and
> 32-bits plugins on 64-bits hosts. I doubt we can drop universal binaries
> just yet.

10.7 does not run on 32-bits machine anymore.

Hub

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

Re: Mac OS X 10.5 Support Plans (Updated)

2012-07-30 Thread Alex Keybl 
+1 to what Mike said. https://en.wikipedia.org/wiki/Mac_OS_X_Snow_Leopard

> Mac OS X Snow Leopard (10.6) was the last release of Mac OS X to support the 
> 32-bit Intel Core Solo and Intel Core Duo CPUs.


Steven would have more info on 32-bit plugins on a 64-bit host, as I'm not sure 
any of the 32-bit binary/library slices are ever loaded on a 64-bit machine 
(could definitely be wrong though).

-Alex

On Jul 30, 2012, at 1:29 AM, Mike Hommey  wrote:

> On Mon, Jul 30, 2012 at 09:23:43AM +0100, Mark Banner wrote:
>> On 19/07/2012 21:38, Alex Keybl wrote:
>>> Thanks to everyone who joined this discussion. We've now moved
>>> forward with disabling OS X 10.5 support for FF17 in [1]. Per
>>> discussion here, we will strive to leave code in place through the 17
>>> cycle, but if it becomes difficult to accomplish necessary work, we
>>> may end up breaking things to advance our goals for supported Mac
>>> versions.
>> 
>> Will we also be stopping the universal binaries? AIUI the 32 bit
>> part was only kept around for the 10.5 support, and running 32 bit
>> on 10.6 is unsupported.
>> 
>> Hence I don't think we need the 32 bit part any more?
> 
> There are two things for which 32-bit is required: 32-bits-only Mac
> (they exist, and they run 10.6 just fine ; not sure about 10.7), and
> 32-bits plugins on 64-bits hosts. I doubt we can drop universal binaries
> just yet.
> 
> Mike
> ___
> 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: Switching nsnull to nullptr

2012-07-30 Thread Aryeh Gregor 
On Wednesday, July 25, 2012 12:45:52 PM UTC+3, Aryeh Gregor wrote:
> The C++11 standard defines a new dedicated null-pointer symbol, "nullptr".  
> It provides better type-safety than existing null-pointer definitions, 
> because it doesn't allow implicit conversion to numeric types.  In 
>  I defined "nullptr" to 
> mean 0L/0LL (like current nsnull) where unsupported, then redefined "nsnull" 
> to mean "nullptr".  This caught a bunch of places where people were using 
> nsnull to mean crazy things like NS_OK or other things that happened to equal 
> 0.
> 
> 
> 
> The next step is to s/nsnull/nullptr/ in the codebase, and get rid of nsnull. 
>  There's no reason for us to use our own identifier when there's a standard 
> one.  This will be of comparable scale to the PRBool elimination of last year 
> -- around 20,000 lines changed instead of 30,000.  This will of course 
> insta-bitrot any patches that people have that mention "nsnull" anywhere, but 
> a shell script will be provided to auto-fix them, as with the PRBool switch 
> (something like "sed -i s/\bnsnull\b/nullptr/ .hg/patches{,-*}/*" should do 
> it).
> 
> 
> 
> This message is of general interest because after the switch, "nsnull" will 
> no longer work, and patch queues will have to be updated.  Also, anyone who 
> maintains a branch will want to figure out how to avoid merge pain.

This is now done on m-c:

http://hg.mozilla.org/mozilla-central/rev/b5c4b792f3f2

Ehsan is going to watch the tree and handle the m-i merge.  To un-bitrot your 
Mercurial patches, you can use the script provided here:

https://bugzilla.mozilla.org/show_bug.cgi?id=626472#c40
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

DOM Bindings Meeting - Monday @ 12:30 PM PDT

2012-07-30 Thread Kyle Huey 
Our weekly DOM bindings meetings continue on Monday July 30th at 12:30 PM
PDT.

Meeting details:

* Monday, July 30, 2012, 12:30 PM PDT
* Conference room 4-M, Mountain View office, 4th floor.
* Conference room 7-N, San Francisco office, 7th floor.
* Wherever I'm sitting, Terminal B, National Airport
* Dial-in Info:
 - Vidyo room: SFO-7N
 - In office or soft phone: extension 92
 - US/INTL: 650-903-0800 or 650-215-1282 then extension 92
 - Toll-free: 800-707-2533 then password 369
 - Conference num 95704
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Mac OS X 10.5 Support Plans (Updated)

2012-07-30 Thread Boris Zbarsky 

On 7/30/12 4:23 AM, Mark Banner wrote:

Will we also be stopping the universal binaries? AIUI the 32 bit part
was only kept around for the 10.5 support


It was also kept around to allow running 32-bit plug-ins in a 32-bit 
plug-in process, no?


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

Re: Mac OS X 10.5 Support Plans (Updated)

2012-07-30 Thread Mike Hommey 
On Mon, Jul 30, 2012 at 09:23:43AM +0100, Mark Banner wrote:
> On 19/07/2012 21:38, Alex Keybl wrote:
> >Thanks to everyone who joined this discussion. We've now moved
> >forward with disabling OS X 10.5 support for FF17 in [1]. Per
> >discussion here, we will strive to leave code in place through the 17
> >cycle, but if it becomes difficult to accomplish necessary work, we
> >may end up breaking things to advance our goals for supported Mac
> >versions.
> 
> Will we also be stopping the universal binaries? AIUI the 32 bit
> part was only kept around for the 10.5 support, and running 32 bit
> on 10.6 is unsupported.
> 
> Hence I don't think we need the 32 bit part any more?

There are two things for which 32-bit is required: 32-bits-only Mac
(they exist, and they run 10.6 just fine ; not sure about 10.7), and
32-bits plugins on 64-bits hosts. I doubt we can drop universal binaries
just yet.

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

Re: Mac OS X 10.5 Support Plans (Updated)

2012-07-30 Thread Mark Banner 

On 19/07/2012 21:38, Alex Keybl wrote:

Thanks to everyone who joined this discussion. We've now moved
forward with disabling OS X 10.5 support for FF17 in [1]. Per
discussion here, we will strive to leave code in place through the 17
cycle, but if it becomes difficult to accomplish necessary work, we
may end up breaking things to advance our goals for supported Mac
versions.


Will we also be stopping the universal binaries? AIUI the 32 bit part 
was only kept around for the 10.5 support, and running 32 bit on 10.6 is 
unsupported.


Hence I don't think we need the 32 bit part any more?

If we do drop that, then I believe that'd be a significant reduction on 
our build & release systems...


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