Re: Running mousemove events from the refresh driver

2013-02-24 Thread Neil

Robert O'Callahan wrote:


WM_MOUSEMOVE events, like other native events, would still take priority over 
all Gecko events and potentially starve the refresh driver.
 

Sorry, I misread the code, I didn't realise that it only prioritised 
keyboard and mouse events over other native events.


--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Accessing @mozilla.org/xmlextras/xmlhttprequest;1 from content

2013-02-24 Thread matthew
On Sunday, February 24, 2013 4:27:16 AM UTC+1, Brian Smith wrote:
 I notice that your company has developed a cross-browser framework for 
 building extensions. That means you are probably familiar with Chromium's 
 requirements here. I believe that Chromium requires you to do things the same 
 way as the Firefox Addon SDK recommends. (I'm not sure if that helps explain 
 my suggestion or not.)

Exactly, we need to emulate Chrome's behavior in the background window (see 
http://developer.chrome.com/extensions/xhr.html). Specifically we need to be 
able to make cross-domain requests in the background window and requests to 
chrome:// and resource:// URLs. I've implemented the background window as a 
hidden XUL window with a browser embedded.

Looking over my code before the switch from FF18 to FF19, I wasn't actually 
doing anything at all except setting the type attribute of the browser to 
chrome (i.e. the default). Unfortunately I'm relying on DOMWindowCreated to 
inject my symbols into the window, and this is no longer fired in FF19 with the 
type set to chrome. I guess I'll file a bug about this.

I was naively looking for a quick fix by injecting my own XHR implementation 
but it looks like that's problematic as I described in my OP. I'll see if I can 
use the content-document-global-created notification or something.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


daily build of xulrunner runtime unstable trunk for mac platform broken

2013-02-24 Thread allencblee
The daily build of xulrunner runtime for mac in the unstable trunk (21a and 
22a) are broken (only 46 bytes).  Any idea what the problem is?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Accessing @mozilla.org/xmlextras/xmlhttprequest;1 from content

2013-02-24 Thread Boris Zbarsky

On 2/24/13 12:44 PM, matt...@salsitasoft.com wrote:

Unfortunately I'm relying on DOMWindowCreated to inject my symbols into the 
window, and this is no longer fired in FF19 with the type set to chrome.


Uh code inspection and basic testing over here suggest it fires just 
fine, for what it's worth.


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