nsIDocument::GetDocShell is not present in any Gecko 31/Windows .lib files

2014-08-19 Thread Look, Yuriy
Hi,

I am building my code against Gecko 31 for Windows and a public C++ method 
nsIDocument::GetDocShell defined in include\nsIDocument.h on line 1188 does not 
get resolved by Visual Studio 2010 linker.  This is the only one that does not 
get resolved for me, even though my code uses quite a few, including several 
more methods of nsIDocument interface.  Your help is very much appreciated.

Thank you,

Yuriy Look | Software Developer | Compuware APM
yuriy.l...@compuware.commailto:yuriy.l...@compuware.com   313  227 3107
...
Simply Smarter APM | 
Compuware.com/APMhttp://www.compuware.com/en_us/application-performance-management.html?utm_source=signatureutm_medium=email
 | APM 
bloghttp://apmblog.compuware.com/?utm_source=signatureutm_medium=email | 
dynaTrace Free 
Trialhttp://www.compuware.com/en_us/application-performance-management/products/dynatrace-free-trial.html?utm_source=signatureutm_medium=email

The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


RE: dev-platform Digest, Vol 103, Issue 47

2014-08-19 Thread Look, Yuriy
Thank you, Boris, this explains my problem.


On Tue, 19 Aug 2014 15:10:38 -0400  Boris Zbarsky bzbar...@mit.edu wrote:
On 8/19/14, 2:52 PM, Look, Yuriy wrote:
 I am building my code against Gecko 31 for Windows and a public C++ method 
 nsIDocument::GetDocShell defined in include\nsIDocument.h on line 1188 does 
 not get resolved by Visual Studio 2010 linker.

This is a non-virtual non-inline method, with default (hidden) visibility.  So 
it can only be used from inside libxul, no?

 This is the only one that does not get resolved for me, even though my code 
 uses quite a few, including several more methods of nsIDocument interface.

Are those also non-virtual and non-inline?

-Boris


The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


RE: nsIBrowserDomWindow question

2013-11-24 Thread Look, Yuriy
Please disregard the message I've sent earlier (below).  I so far ended up not 
using the class.

-Original Message-
From: Look, Yuriy 
Sent: Friday, November 22, 2013 8:32 PM
To: dev-platform@lists.mozilla.org
Subject: nsIBrowserDomWindow question

Hi,

nsIBrowserDomWindow does not get recognized in C++ code, even though 
nsIBrowserDomWindow.h is #included.  Do I need to do anything differently 
compare to other interfaces? 

Thank you in advance,

Yuriy Look | Software Developer | Compuware APM yuriy.l...@compuware.comĀ   



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


nsIBrowserDomWindow question

2013-11-22 Thread Look, Yuriy
Hi,

nsIBrowserDomWindow does not get recognized in C++ code, even though 
nsIBrowserDomWindow.h is #included.  Do I need to do anything differently 
compare to other interfaces? 

Thank you in advance,

Yuriy Look | Software Developer | Compuware APM
yuriy.l...@compuware.comĀ   



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


17.0.11 and 24.1.1 XULRunner?

2013-11-20 Thread Look, Yuriy
Hi,

On or around November 13 2013 Firefox of versions 25.0.1, 24.1.1 ESR and 17.0.1 
ESR were rereleased, along with XULRunner 25.0.1, but not for ESR versions.  My 
question is was any incompatibilities between Fx and XULRunner introduced with 
these releases, and if so, did those incompatibilities affect ESR versions?  If 
the answer is Yes, I think it would be appropriate to rerelease XULRunner for 
ESR versions, like it was once done for Bug 
757652https://bugzilla.mozilla.org/show_bug.cgi?id=757652.  Can anyone check 
on this?

Thank you,

Yuriy Look | Software Developer | Compuware APM
yuriy.l...@compuware.commailto:yuriy.l...@compuware.com
...
Simply Smarter APM | 
Compuware.com/APMhttp://www.compuware.com/en_us/application-performance-management.html?utm_source=signatureutm_medium=email
 | Facebookhttp://www.facebook.com/CompuwareAPM | 
Twitterhttp://www.twitter.com/CompuwareAPM | 
APMbloghttp://apmblog.compuware.com/?utm_source=signatureutm_medium=email | 
Google+http://gplus.to/CompuwareAPM



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


RE: Capturing text from Firefox

2013-10-18 Thread Look, Yuriy
Benjamin,

Thank you very much for the answers.  We'll need to way our options.  

Thank you,

Yuriy


-Original Message-
From: Benjamin Smedberg [mailto:benja...@smedbergs.us] 
Sent: Friday, October 18, 2013 8:55 AM
To: Look, Yuriy; dev-platform@lists.mozilla.org
Subject: Re: Capturing text from Firefox

On 10/17/2013 7:30 PM, Look, Yuriy wrote:
 I am working on GUI automation component of a performance monitoring product. 
  One of the common approaches to monitoring application is periodically 
 capture text from the control where changes are expected (content area of the 
 browser for Web applications).  Text capturing ideally captures all text, 
 including not selectable and user input.
Have you looked into reusing the existing Selenium browser automation? 
http://docs.seleniumhq.org/

It's not clear exactly what kinds of problems you are trying to solve, but the 
Mozilla content layer already has ways to expose pretty much all of the DOM 
text, including nonselectable text, via various APIs including the DOM itself, 
accessibility API, and some other lower-level functions we use for find-in-page.

 In the product I work on this is achieved by (1) forcing the application to 
 re-draw the texts in the window or part of the window of interest and (2) 
 hooking the functions that responsible for text drawing during the time 
 interval of the capturing is performed.  Hooking is performed by modifying 
 the first bytes of the binary code of the hooked functions to jump to the 
 hooking functions, which process the same parameters and then jump back to 
 allow the hooked function to perform their job.
This will certainly not work in the future, see below.

 Which functions/technologies are drawing the text?
  Is drawing performed by normal Windows APIs, like DrawTextEx or 
 ExtTextOut, or this is no longer the case?
No. If I'm reading our bugs correctly, we're currently using a combination of 
harfbuzz (http://freedesktop.org/wiki/Software/HarfBuzz/)
and uniscribe/directwrite. We use uniscribe only for Hangul, Mongolian, Indic, 
and Thai text, and intend to eventually use harfbuzz for all text rendering.
  Does it delegates drawing to another process?
Not yet, but we're working on having content processes similar to the way many 
other web browsers do.
 Does Ff caches drawn text, say, in memory device contexts, so that in case 
 the window or a region needs to be repainted, text does not need to be 
 redrawn and widow device context is updated through functions like BitBlt?
Yes.
If so, can such caching be disabled programmatically or through 
 configuration?
No, I don't think it's possible to disable the layer system any more.
 Does Ff patch Windows DLLs?
In a few specific cases, yes, but primarily to enforce a DLL blocklist for 
stability issues and to ensure that our crash reporting system isn't tampered 
with. In plugin processes we also hook a few event-system functions. I don't 
think that any of our hooking should affect the graphics/text subsystems.



 Are there other approaches to capturing text form Ff you can suggest?
Ultimately, I don't think that trying to capture text by hooking drawing 
functions is going to be successful in Firefox. You probably need to look at 
some combination of accessibility and DOM APIs, depending on your actual use 
case.

--BDS



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


Capturing text from Firefox

2013-10-17 Thread Look, Yuriy
Hi,

I am working on GUI automation component of a performance monitoring product.  
One of the common approaches to monitoring application is periodically capture 
text from the control where changes are expected (content area of the browser 
for Web applications).  Text capturing ideally captures all text, including not 
selectable and user input.

In the product I work on this is achieved by (1) forcing the application to 
re-draw the texts in the window or part of the window of interest and (2) 
hooking the functions that responsible for text drawing during the time 
interval of the capturing is performed.  Hooking is performed by modifying the 
first bytes of the binary code of the hooked functions to jump to the hooking 
functions, which process the same parameters and then jump back to allow the 
hooked function to perform their job.

In relation to Firefox, his worked well with releases up to 10 ESR (starting 
from 10, we implement support only to ESR releases), even though with each Ff 
release forcing the text to be redrawn was more and more difficult.

In relation to this I have questions related to both Ff17 and Ff24 (I assume 
that some answers might be not the same for these releases):

Which functions/technologies are drawing the text?
Is drawing performed by normal Windows APIs, like DrawTextEx or 
ExtTextOut, or this is no longer the case?
Does Ff use some Microsoft technology which was not used before?
Does Ff use its own text drawing functions?
Does it delegates drawing to another process?
BTW. In relation to these questions, even if I disable use of Direct2D and 
Direct Write according to 
http://forums.mozillazine.org/viewtopic.php?t=1775755, I still see DWrite.dll 
loaded into Firefox.exe process.

Does Ff caches drawn text, say, in memory device contexts, so that in case the 
window or a region needs to be repainted, text does not need to be redrawn and 
widow device context is updated through functions like BitBlt?  If so, can such 
caching be disabled programmatically or through configuration?

Does Ff patch Windows DLLs?

Are there other approaches to capturing text form Ff you can suggest?

Any help is very much appreciated.

Thank you,

Yuriy Look | Software Developer | Compuware APM
yuriy.l...@compuware.commailto:yuriy.l...@compuware.com   313  227 3107
...
Simply Smarter APM | 
Compuware.com/APMhttp://www.compuware.com/en_us/application-performance-management.html?utm_source=signatureutm_medium=email
 | Facebookhttp://www.facebook.com/CompuwareAPM | 
Twitterhttp://www.twitter.com/CompuwareAPM | 
APMbloghttp://apmblog.compuware.com/?utm_source=signatureutm_medium=email | 
Google+http://gplus.to/CompuwareAPM



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