This isn't directly a coding question, but answers to this will help in coding a Firefox addon.
Is all JS addon code executed on main thread?
Assuming question to above is 'yes', could the addon code be executed by different JS runtimes on the main thread?
Assuming answer to #2 is 'no', are there multiple JS 'execution contexts' within the same JS runtime? If 'yes', could the addon code be executed by different execution contexts within the same JS runtime?
I could be way off in my above questions, but I am seeing a strange behavior in my addon that is causing parts of my addon code to hang (when a modal dialog is up, am not able to receive data on socket #1), but other parts continue working (am able to read data from socket #2). I am not able to explain the behavior.
Is all JS addon code executed on main thread?
Yes. AFAIK the only exception to this rule is code you run via web workers or ChromeWorker. There were plans to run extensions based on the Add-on SDK in a different process, I'm not sure whether this is still the goal.
could the addon code be executed by different JS runtimes on the main thread?
Theoretically - yes. E.g. an extension could come with a binary XPCOM component containing a different JavaScript engine. Or there is the Zaphod extension coming with a JavaScript-based JavaScript engine. But that doesn't really matter to your code running in the regular SpiderMonkey engine.
I am seeing a strange behavior in my addon that is causing parts of my addon code to hang (when a modal dialog is up, am not able to receive data on socket #1)
JavaScript execution is based on event queues - the browser will take an event from the queue (could be for example a DOM event, a timeout, a network event) and process it which will run corresponding JavaScript code. No other events can be processed until this JavaScript code finishes.
However, JavaScript code doesn't continue to run when a modal dialog is open or a synchronous XMLHttpRequest is performed - yet events still need to be processed. This is solved by modal dialogs and XMLHttpRequest doing event processing while they are active (they spin their own event loop).
So far the basics. Data coming in on a socket is a regular event - and it should work regardless of whether it is being processed by the main event loop or by the modal dialog's loop.
Related
If I'm running some JavaScript in my iOS app using JavaScriptCore, is it possible for my native code to query whether the JavaScript is currently processing an event, and/or whether there are events waiting to be immediately processed next?
Scenario: the running JS is managing some state, and I want my UI thread to occasionally query the JS for that state, but I don't want to risk waiting too long if the JS is busy processing other events first.
I investigated a bit more, and discovered that there's a surprising answer for this question: there is no javascript event loop in JSCore, if you don't implement it.
To add further detail, execution of javascript code is always synchronous with the ObjC function that invokes it, and there is no method in Javascript to generate asynchronous execution: no setTimeout, no setInterval, no DOM and addEventListener. You have to implement these function natively, and then you have to decide the scheduling policy. If your JSContext is attached to a WebView or similar browser-like context, the WebView provides these events, and you may not be able to access them in the way you want. In this case however you may use something like Zone.js to monkey patch all functions which may generate events and implement in Javascript something that tracks what you want (which is something that's done in the video of the presentation of the technology, in the linked page)
Based on a quick perusal of the API source here:
https://github.com/phoboslab/JavaScriptCore-iOS/tree/master/JavaScriptCore/API
I don't see any function on the JSContext or JSVirtualMachine that would get you the information you're interested in.
As an alternative, you could do a callback to your ObjC code from JS each time the JS code begin/ends processing an event, and then store state information in the ObjC side so you can quickly determine if you believe the JSVM is processing an event or not.
So I'm using capybara to test my backbone app. The app uses jquery animations to do slide transitions.
So I have been getting all kinds of weird issues. Stuff like element not found ( even when using the waiting finders and disabling the jquery animations ) I switched from the chrome driver back to Firefox and it fixed some of the issues. My current issues include:
Sometimes it doesn't find elements if the browser window is not maximized even though they return true for .visible? if I inspect w pry. (this is a fixed with slide w no responsive stuff )
and the following error:
Failure/Error: click_link "Continue"
Selenium::WebDriver::Error::StaleElementReferenceError:
Element not found in the cache - perhaps the page has changed since it was looked up
Basically, my questions are:
what am I doing wrong to trigger these issues.
can you tell me what if I have any other glaring issues in my code?
and when using a waiting Finder, do I need to chain my click to the returned element to ensure it has waited correctly or can I just find the element and call the click on another line:
Do I have to chain like this
page.find('#myDiv a').click_link('continue')
Or does this work?
page.find('h1').should have_content('Im some headline')
click_link('continue')
Here is my code: http://pastebin.com/z94m0ir5
I've also seen issues with off-screen elements not being found. I'm not sure exactly what causes this, but it might be related to the overflow CSS property of the container. We've tried to work around this by ensuring that windows are opened at full size on our CI server, or in some cases scrolling elements into view by executing JavaScript. This seems to be a Selenium limitation: https://code.google.com/p/selenium/issues/detail?id=4241
It's hard to say exactly what's going wrong, but I'm suspicious of the use of sleep statements and a lot of use of evaluate_script/execute_script. These are often bad signs. With the waiting finder and assertion methods in Capybara, sleeps shouldn't be necessary (you may need to set longer wait times for some actions). JavaScript execution, other than being a poor simulation of how the user interacts with the page, don't wait at all, and when you use jQuery, actions on selectors that don't match anything will silently fail, so that could result in the state of the page not being correct.
You do not have to chain. Waiting methods in Capybara are all synchronous.
I have a DirectShow filter created with Delphi Pro 6 and the DSPACK direct show library. I'm running under windows XP. I've tried creating the form dynamically when the container class for the DirectFilter has its constructor called, passing NIL into the constructor as the AOwner parameter (TMyForm.Create(nil) and then calling the Form's Show() method. The form does show but then appears to stop receiving windows messages because it never repaints and does not respond to input. As a test I then tried creating my own WndProc() and overriding the Form's WndProc(). My WndProc() did get called once but never again.
I'm guessing it's because I'm a DLL and the context that I am running in is not "friendly" to the window message handler for the form; perhaps something to do with the thread that calls it or whatever. If someone could give me a tip on how to solve this or what the proper way to create a persistent window is from the context of a DirectShow filter I'd appreciate it. Note, as I said the window needs to be persistent so I can't create it as a Filter property page.
Thanks,
Robert
I can't help you with the DirectShow filter specifics, but I feel that some general information about windows and message handling might help.
Windows have thread affinity, which means that all messages for a window will be handled in the context of the thread that created it. That means that this thread needs to have the standard message processing loop, the low level equivalent of Application.ProcessMessages(). Both messages from the same and from other threads will be queued in the message queue of the creating thread, and the message loop will get them, (optionally) translate them, and dispatch them to the window handler of the target window.
What you are describing could be caused by either
not having a message processing queue in the thread that creates the window, or
creating the window in the wrong thread
(Note that these are essentially the same, but stated like this it becomes apparent that there may be different problems that cause this, which need to be fixed in different ways - either the window needs to be created in a different thread, or a processing loop needs to be created in the thread.)
You need to find out which of the two causes your window not to process messages. You don't necessarily need to override WndProc(), message handling methods for distinct messages will work (or not work) the same. That your WndProc() was called once doesn't really tell you much, because under some circumstances messages sent from the same thread will be handled without the message loop, by calling the window proc directly.
Since your filter resides in a DLL I don't think that creating your own message loop would be the right thing. This works for a modal dialog, which will be created, the message loop will run until the dialog is closed, and then the message loop will terminate and the DLL function will return. It will not work for a DLL exported function that will be called and needs to return all while the message loop is still running. I assume the framework that creates and calls those filters will handle the message loop as well. However, that is a gut feeling, not knowing about DirectShow filters this may well be wrong.
What might help you to debug this is a tool like Spy++ from Visual Studio, with which you can show information about windows, log messages sent to them or to all windows in the same process or thread, show window hierarchies and do a lot of other interesting things. If you don't have that, there are a lot of clones (some freeware) on the net, which Google should turn up. Trying to show the messages sent to all windows of the same thread or process should tell you whether a message loop is running. You should also be able to get more information by running SysInternals Process Explorer or similar tools.
Is there another way to load MSHTML documents without use Application.ProcessMessages?
To load a document into a IHTMLDocument I need to do this:
while Doc.readyState <> 'complete' do
Application.ProcessMessages;
I want not to process all the message queue during the loading, because I would be changing my application flow, in other words, some messages that should be processed after the loading to be completed can be processed earlier, even before the loading end.
There is a special message code that the IHTMLDocument expect to advance in the loading process? Or there is another way to load?
The call to Application.ProcessMessages is most likely just needed to allow the MSHTML activeX control time to finish loading the document. It sounds like they're using cooperative multitasking here to simulate loading the doc in the background - the ActiveX posts messages to itself to process the next chunk or whatever.
Normally, this wouldn't affect your app's flow because the doc load would happen as part of your normal message loop. But because you're wanting to load the doc synchronously (not do anything else until the doc is fully loaded), you're sensitive to the way it's doing background loading via messages.
One solution: see if you can remove the requirement to load the doc synchronously. Let the load happen when it happens, but move the check for readState = complete into a timer, perhaps on a 1 second interval. When the timer discovers the doc load is complete, then fire off your downstream food chain activities.
Another solution: Display a modal dialog while waiting for the doc to load. This has the benefit of disabling the rest of your UI so you don't run the risk of reentrancy. Calling ProcessMessages means the user can still interact with your window, click on buttons, menus etc. Usually this will lead to problems. Displaying a modal dialog ("progress dialog?") avoids reentrancy by disabling everything behind the modal dialog.
Third possibility: Replace Application.ProcessMessages with PeekMessage and logic to examine the message to decide whether to let it go through or put it back on the message queue for later. This is a bit dirty but might work in very special cases.
I recommend approach #2, the modal dialog.
The component TEmbeddedWB contains some helper functions such as LoadFromFile and LoadFromStream which will load the document into the MSHTML control directly. Move your complete logic into the onDocumentComplete event.
There is a TEmbeddedWB.OnDocumentComplete event, fired when a document completes loading. Is there any special reason why you don't want to use that?
I'm developing a application in Lazarus, that need to check if there is a new version of a XML file on every Form_Create.
How can I do this?
I have used the synapse library in the past to do this kind of processing. Basically include httpsend in your uses clause, and then call httpgetbinary(url,xmlstream) to retrieve a stream containing the resource. I wouldn't do this in the OnCreate though, since it can take some time to pull the resource. Your better served by placing this in another thread that can make a synchronize call back to the form to enable updates, or set an application flag. This is similar to how the Chrome browser displays updates on the about page, a thread is launched when the form is displayed to check to see if there are updates, and when the thread completes it updates the GUI...this allows other tasks to occur (such as a small animation, or the ability for the user to close the dialog).
Synapse is not a visual component library, it is a library of blocking functions that wrap around most of the common internet protocols.
You'll need to read up on FPC Networking, lNet looks especially useful for this task.