DDE queries for WWW_GetWindowInfo to programatically get URL stopped working starting version 49. Has DDE support stopped?
I use the following code (in C#) to programmatically obtain a Firefox window's current URL:
public static string GetFirefoxURL()
{
DdeClient dde = new DdeClient("Firefox", "WWW_GetWindowInfo");
dde.Connect();
string url = dde.Request("URL", int.MaxValue);
dde.Disconnect();
return url;
}
This worked fine until v. 48, but starting in v. 49 it started returning the ff error. I'm using NDDE as my library to call the client:
Exception thrown: 'NDde.DdeException' in NDde.dll ("The client failed to request "Firefox|WWW_GetWindowInfo!URL".")
Can someone please point me to the right direction on fixing this?
Thanks.
Усі відповіді (4)
I see the same issue here: http://stackoverflow.com/questions/40103630/ndde-ddeexception-the-client-failed-to-request-firefoxwww-getwindowinfourl (unsolved).
Is your Firefox 49 running in Multiprocess mode?
Multiprocess (e10s)
One of the headline changes in Firefox 48+ is e10s, which separates the browser interface process from the page content process. More and more users are gradually having this multiprocess feature switched on. The feature usually is implemented as two distinct firefox.exe processes, once for the browser "chrome" and one for the "content."
I don't know whether this is relevant to your experience, so let's check.
Are you using e10s?
You can confirm you have this feature turned on from inside Firefox as follows. Either:
- "3-bar" menu button > "?" button > Troubleshooting Information
- (menu bar) Help > Troubleshooting Information
- type or paste about:support in the address bar and press Enter
In the first table on the page, check the row for "Multiprocess Windows" and see whether the number on the left side of the fraction is greater than zero. If so, you are using e10s.
If you are using e10s:
You could evaluate whether e10s is causing your issue by turning it off as follows:
(1) In a new tab, type or paste about:config in the address bar and press Enter/Return. Click the button promising to be careful.
(2) In the search box above the list, type or paste autos and pause while the list is filtered
(3) Double-click the browser.tabs.remote.autostart.2 preference to switch the value from true to false
Note: the exact name of the preference may vary, but it will start with browser.tabs.remote.autostart
At your next Firefox startup, it should run in the traditional way. Any difference?
Thank you for the reply. Yes, this is exactly the case.
Unfortunately for me the PCs being monitored are not in our direct control (this is for a time/productivity tracking software), so this means I won't be able to ask everyone to execute the steps you recommended.
If there's any other recommendation you can make in terms of how to request the same information via DDE, it would be well appreciated.
That was just a guess as to what might have changed. Can someone test whether that is the source of the problem?
This thread mentions Multiprocess being an issue for DDE getting web page URLs, but that it still gets internal pages, like the built-in Firefox home page (about:home), Add-ons page (about:addons), etc. You can check various internal pages by typing about:about in the address bar and following some links there.
https://autohotkey.com/boards/viewtopic.php?t=15734
Do you notice any pattern like that in your data?