Closed Bug 256418 (roboform-crash) Opened 20 years ago Closed 17 years ago

FF10x M17x Roboform crashes [@ nsQueryInterface::operator] [@ RoboForm.dll]

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Version:
1.0 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: yale631, Assigned: morgamic)

References

(
URL
)

Details

(4 keywords)

Crash Data

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040803 Firefox/0.9.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040803 Firefox/0.9.3

Throughout the times, the stability between Roboform and ascending Firefox
versions has increased. But There are still some circumstances, where the
conjunction of Firefox and Roboform causes a crash. I have noticed these crashes
only occur when a conflicting web page is visited.

To see an example of a valid argument. Follow the steps listed below in a
Windows XP Home (if possible SP2) environment.

1. Install Firefox v0.9.3
2. Install Roboform v5.7.6, or v6.03
3. Install Roboform Mozilla/Firefox adapter v5.7.4
4. If not currently installed, install Tabbrowser Extensions v1.10.2004071201
5. Visit http://www.invisonfree.com/forum/
6. Close the tab with the above URL.

You then should receive an error dialog from Windows stating that Firefox needs
to close, and asking if do you want to send an error report.

If you were to uninstall the Roboform Adapter, and repeat steps 5-6, Firefox
would not crash and you would receive no error dialog at all. Therefore, one
could conclude that there was a conflict between the web page, Firefox, and
Roboform.

This was originally a post from
http://forums.mozillazine.org/viewtopic.php?t=114685, made in the Firefox Bug
Forum by me.

Reproducible: Always
Steps to Reproduce:
1. Install Firefox v0.9.3
2. Install Roboform v5.7.6, or v6.03
3. Install Roboform Mozilla/Firefox adapter v5.7.4
4. If not currently installed, install Tabbrowser Extensions v1.10.2004071201
5. Visit http://www.invisonfree.com/forum/
6. Close the tab with the above URL.

Actual Results:  
You then should receive an error dialog from Windows stating that Firefox needs
to close, and asks do you want to send an error report.

Expected Results:  
The software should have been able to close the window, and return to a normal
state of browsing. 

I am using the default theme. The site  http://www.invisonfree.com/ is just one
of the possible millions more that could have the same or similar conflict with
Firefox and/or Roboform. In previous versions (0.9.1 and 0.9.2) Attempting to
casually browse or post at http://www.forums.govteen.com/ would cause a similar
crash. Or attempting to sending a message at
http://neopets.com/neomessages.phtml?type=send would cause the page to crash
before it finished loading. I ignored these issues, and upon the release of
0.9.3 they disappeared. But now I think it be more beneficial if attention where
brought to them and others, instead of me ignoring them since the release of 1.0
approaches. By then I want to be fully converted to Firefox. One thing that
surprised me, even as I typed this report up, Firefox crashed, luckily I have
Scribe installed.
Travis: Could you provide TalkBack incident ID?
Severity: normal → critical
Component: Browser-General → General
Product: Browser → Firefox
Summary: Browser crashes if I close the window. → FF093 with Roboform crashes if I close the window
Version: Trunk → 1.0 Branch
(In reply to comment #1)
> Travis: Could you provide TalkBack incident ID?

Where is this found?
same problem here.
using xp home sp2, firefox 0.9.3, roboform.
however, i don't use Tabbrowser Extensions.

talkback incident id is: TB670863E
Travis: When your Firefox crash, TalkBack Quality FeedBack Agent dialog appear.
It will ask you for sending report to Mozilla.org. Send it and then go to your
Firefox directory and in components subdirectory start talkback.exe. You will
get list of ids like TB456455Y, pick top and put it to this bug report as comment.

Jules' TB670863E contains just 0x00000000.
When I send a report it never goes through.
What is being done to correct the issue?
problem seems fixed with latest roboform version 6.0.6 + latest roboform mozilla
adapter 6.0.4
Confirmed 2x on mozillazine.  

I find FF1.0PR crashes randomly a few times a day,
I don't have a talkback ID, but logged the talkbacks to my email address in the
form of firstname@lastname.com. (matthew@el...).   

See response from RF (RoboForm) support on mozillazine thread - RF think they're
at fault and are working to fix their code.  

Suggestion: add something to the release notes?
(http://www.mozilla.org/products/firefox/releases/)
Status: UNCONFIRMED → NEW
Ever confirmed: true
TalkBack IDs: TB940272Y, TB923046X, TB922669X, TB906710Z, TB905971Y
Keywords: talkbackid
Summary: FF093 with Roboform crashes if I close the window → FF10PR1 with Roboform crashes if I close the window
Oh, and Jules: my crashes were with RF 6.0.7, Gecko Adapter 2004-06-23-1.7.
I'll be trying FF10PR1 with RF6.0.9 shortly.
This has been showing up towards the bottom of the topcrash lists for Firefox
1.0 PR1, RC1 and RC2.  Most of the incidents are coming from only a few users,
so marking this topcrash-.  Adding topcrash info for tracking.
Keywords: talkbackid → topcrash-
Summary: FF10PR1 with Roboform crashes if I close the window → FF10RC2 Roboform crashes if I close the window [@ RoboForm.dll]
Well, this has moved up to the #7 topcrash for Firefox 1.0, so marking topcrash+
to get some more traction.  Looks like we already have a reproducible testcase,
so hopefully we can figure out what's going on and whether there is anything we
can do from our end to prevent this crash.
Keywords: topcrash- → topcrash+
Summary: FF10RC2 Roboform crashes if I close the window [@ RoboForm.dll] → FF10 Roboform crashes if I close the window [@ RoboForm.dll]
Returning to normal topcrash and adding M17 to summary since there are a few
crashes for RoboForm in Mozilla 1.7x.  Still have not been able to
reproduce...adding helpwanted keyword to see if we can get others to help out.
Keywords: topcrash+ → helpwanted, topcrash
Summary: FF10 Roboform crashes if I close the window [@ RoboForm.dll] → FF10 M17 Roboform crashes if I close the window [@ RoboForm.dll]
This is a major crasher for Mozilla 1.0.4 and is currently crashing the latest
1.0.5 builds.  Roboform is still crashing Firefox 1.0.x, just under a different
stack signature.  Here is a recent incident:

Incident ID: 7025879
Stack Signature	nsQueryInterface::operator() 6d9a3ac3
Product ID	Firefox10
Build ID	2005062617
Trigger Time	2005-06-27 11:40:36.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	xpcom.dll + (0003d1fd)
URL visited	
User Comments	Every 1.0.5 version crashes when roboform extension tries to fill
a form
Since Last Crash	99 sec
Total Uptime	99 sec
Trigger Reason	Access violation
Source File, Line No.
c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Depend/mozilla/xpcom/glue/nsCOMPtr.cpp,
line 47
Stack Trace 	
nsQueryInterface::operator() 
[c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Depend/mozilla/xpcom/glue/nsCOMPtr.cpp,
line 47]
rfproxy.dll + 0x1d378 (0x019fd378)
RoboForm.DLL + 0x43e75 (0x03043e75)
RoboForm.DLL + 0x3b2ae (0x0303b2ae)
OLEAUT32.dll + 0x73d0 (0x770f73d0)
RoboForm.DLL + 0x4ceaf (0x0304ceaf)
RoboForm.DLL + 0x4bd6c (0x0304bd6c)
RoboForm.DLL + 0x3b104 (0x0303b104)
rfproxy.dll + 0x7f82 (0x019e7f82)
rfproxy.dll + 0x7aca (0x019e7aca)
nsEventListenerManager::HandleEvent 
[c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Depend/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1545]
nsDocument::HandleDOMEvent 
[c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Depend/mozilla/content/base/src/nsDocument.cpp,
line 3757]
nsGenericElement::HandleDOMEvent 
[c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Depend/mozilla/content/base/src/nsGenericElement.cpp,
line 2028]
nsGenericElement::HandleDOMEvent 
[c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Depend/mozilla/content/base/src/nsGenericElement.cpp,
line 2022]
nsGenericElement::HandleDOMEvent 
[c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Depend/mozilla/content/base/src/nsGenericElement.cpp,
line 2022]
nsGenericElement::HandleDOMEvent 
[c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Depend/mozilla/content/base/src/nsGenericElement.cpp,
line 2022]
nsGenericElement::HandleDOMEvent 
[c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Depend/mozilla/content/base/src/nsGenericElement.cpp,
line 2022]
nsGenericElement::HandleDOMEvent 
[c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Depend/mozilla/content/base/src/nsGenericElement.cpp,
line 2022]
nsGenericElement::HandleDOMEvent 
[c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Depend/mozilla/content/base/src/nsGenericElement.cpp,
line 2022]
nsGenericElement::HandleDOMEvent 
[c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Depend/mozilla/content/base/src/nsGenericElement.cpp,
line 2022]
nsGenericElement::HandleDOMEvent 
[c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Depend/mozilla/content/base/src/nsGenericElement.cpp,
line 2022]
nsGenericElement::HandleDOMEvent 
[c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Depend/mozilla/content/base/src/nsGenericElement.cpp,
line 2022]
nsGenericElement::HandleDOMEvent 
[c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Depend/mozilla/content/base/src/nsGenericElement.cpp,
line 2022]
nsGenericElement::HandleDOMEvent 
[c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Depend/mozilla/content/base/src/nsGenericElement.cpp,
line 2022]
nsGenericElement::HandleDOMEvent 
[c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Depend/mozilla/content/base/src/nsGenericElement.cpp,
line 2022]
nsGenericElement::HandleDOMEvent 
[c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Depend/mozilla/content/base/src/nsGenericElement.cpp,
line 2022]
nsGenericElement::HandleDOMEvent 
[c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Depend/mozilla/content/base/src/nsGenericElement.cpp,
line 2022]
nsGenericElement::HandleDOMEvent 
[c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Depend/mozilla/content/base/src/nsGenericElement.cpp,
line 2022]
nsGenericElement::HandleDOMEvent 
[c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Depend/mozilla/content/base/src/nsGenericElement.cpp,
line 2022]
nsGenericElement::HandleDOMEvent 
[c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Depend/mozilla/content/base/src/nsGenericElement.cpp,
line 2022]
nsGenericElement::HandleDOMEvent 
[c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Depend/mozilla/content/base/src/nsGenericElement.cpp,
line 2022]
nsHTMLInputElement::HandleDOMEvent 
[c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Depend/mozilla/content/html/content/src/nsHTMLInputElement.cpp,
line 1409]
PresShell::HandleEventInternal 
[c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Depend/mozilla/layout/html/base/src/nsPresShell.cpp,
line 6059]
PresShell::HandleEvent 
[c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Depend/mozilla/layout/html/base/src/nsPresShell.cpp,
line 5921]
nsViewManager::HandleEvent 
[c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Depend/mozilla/view/src/nsViewManager.cpp,
line 2321]
nsViewManager::DispatchEvent 
[c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Depend/mozilla/view/src/nsViewManager.cpp,
line 2061]
HandleEvent 
[c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Depend/mozilla/view/src/nsView.cpp,
line 77]
nsWindow::DispatchEvent 
[c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 1067]
nsWindow::DispatchMouseEvent 
[c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 5261]
ChildWindow::DispatchMouseEvent 
[c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 5511]
nsWindow::WindowProc 
[c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 1349]
USER32.dll + 0x8734 (0x77d18734)
USER32.dll + 0x8816 (0x77d18816)
USER32.dll + 0x89cd (0x77d189cd)
USER32.dll + 0x8a10 (0x77d18a10)
nsAppShell::Run 
[c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Depend/mozilla/widget/src/windows/nsAppShell.cpp,
line 159]
nsAppShellService::Run 
[c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Depend/mozilla/xpfe/appshell/src/nsAppShellService.cpp,
line 495]
main 
[c:/builds/tinderbox/Fx-Aviary1.0.1-l10n/WINNT_5.1_Depend/mozilla/browser/app/nsBrowserApp.cpp,
line 58]
kernel32.dll + 0x16d4f (0x7c816d4f)

And a set of crashes with user comments:
nsQueryInterface::operator
Crashes: 115 Unique Users: 47
BBID range: 6845157 - 7096629 Date range: 20-JUN-05 to 29-JUN-05
Stack Trace:


Source File:
c:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.2_Depend/mozilla/xpcom/glue/nsCOMPtr.cpp
line : 47

(7031190) msn.com/hotmail
(7025879) Every 1.0.5 version crashes when roboform extension tries to fill a form
(6966120) Roboform does not fit in apparent
(6954055) God damn it you guys. What the Fucking bloody ass-drip is this? Shit
is Ass-drip hyphenated? And should 'A' in 'Ass' be capitalized? Bloody dumpster
diving Mexican burrito dildo dead digger dripper!
(6930701) msn.com/hotmail
(6930701) I was trying to access my e-mail and got the msg. that Firefox
encountered a probllem and must close! Why?
(6897719) http://us.f524.mail.yahoo.com/ym/login?.rand=auagdqnd14kon
(6897719) After upgrading to 1.0.5 tried to go to my e-mail (I have AI Roboform
Pro) and the name and paasword was in place in the log-in I clicked the enter
button CRASH!!! Tried several times same result!!
(6875886) messed up with Roboform
(6864046) http://www.mozillazine.org/talkback.html?article=6819
(6864046) Roboform seems to be causing the crash.
(6864019) http://www.mozillazine.org/talkback.html?article=6819
(6864019) signing with Roboform. Roboform crashed then Firefox.
(6861704) Freeze
(6845157) installin roboform 

We should see if we can find a way to prevent this crash or if we can contact
the authors of Roboform to look into fixing this on their end.
Flags: blocking-aviary1.0.5+
Keywords: topcrash → topcrash+
Summary: FF10 M17 Roboform crashes if I close the window [@ RoboForm.dll] → FF10x M17x Roboform crashes if I close the window [@ RoboForm.dll]
Summary: FF10x M17x Roboform crashes if I close the window [@ RoboForm.dll] → FF10x M17x Roboform crashes [@ nsQueryInterface::operator] [@ RoboForm.dll]
crashes for nsQueryInterface::operator are at 57th on the current (public)
topcrash list, and have at least two other bugs that could be causing that
linked from talkback.  the roboform.dll signature has _one_ crash.

Looking at the stack this is all theirs, and not something that's even remotely
a blocker for 1.0.5 since the crash happens in their code.  If they can fix
their code, great, but blocking 1.0.5 on this is wrong.

If we're thinking band-aid for whatever they're doing wrong, that is also well
outside the scope of what we've been considering for the branch (security
patches and regression fixes from previous branch security fixes).
can someone waste some time using debug builds that work/don't work with nspr
logging of the component manager? figure out what components they're using and
design a way to cause their code to fail to work. it shouldn't be too hard.
Ok, fair.  -'ing this for 1.0.5, I just wanted to get it on the radar so people
took a look to see how bad we thought these were.  Thanks for the input mconner.
 If I continue to see lots of user comments mentioning Robofrom after the
release of 1.0.5, we'll have to contact the Roboform folks to see if they can
help here.
Flags: blocking-aviary1.0.5+ → blocking-aviary1.0.5-
Early Talkback data for Firefox 1.0.5 shows a lot of users crashing with
Roboform, surprise, surprise.  Since this bug has been around for a while, we
need to get it relnoted to make sure users know of the stability issues.  We
also need to get into contact with the Roboform authors to see if they can fix
this on their end.  CC'ing Rafael so we can get this relnoted and let the
Roboform folks know about this.

Here is a link to all 1.0.5 crashes that mention roboform (there are many others
not on this list that lack user comments):
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=comments&match=contains&searchfor=roboform&vendor=All&product=Firefox10&platform=All&buildid=20050711&sortby=bbid
Keywords: relnote
https://addons.mozilla.org/extensions/moreinfo.php?id=750&os=windows&application=firefox
http://www.roboform.com/browsers.html
they clearly list 1.0.4 is the last supported version

morgamic has graciously volunteered to poke this bug for a bit
Assignee: general → morgamic
As predicted, this is clearly the #1 topcrasher for Firefox 1.0.5.  It makes up
nearly 50% of all crashes reports thus far for the new release:
http://talkback-public.mozilla.org/reports/firefox/FF105/FF105-topcrashers.html

Hopefully we will be able to figure this one out soon to save our users a lot of
pain.
Here is the response I got from the Roboform support:

Andrew Steed replied (2005/07/13 04:59 pm EST):
You are using new version of Mozilla, Firefox or Netscape browser  
that is not yet supported by RoboForm Adapter.

After the official dot release of Firefox or Mozilla appears,  
it takes at least one week to add support for it to RoboForm Adapter.  
We are not given any materials in advance by Mozilla.org and it is impossible to
do it any faster.

The news of the new RoboForm Mozilla Adapter release will appear on this page:
http://www.roboform.com/manual.html#browser_nn6.

You can simply Uninstall the RoboForm Adapter by doing this: 
Start > Settings > Control Panel 
Click ADD/REMOVE PROGRAMS 
Find RoboForm Netscape Adater, click UNINSTALL

Or if you have installed the RoboForm Firefox Extension you need to open the
Firefox extensions menu and uninstall the RoboForm extension

---------------------------------

It sucks that something on their end breaks the extension for a 1.0.x release. 
I would understand if it broke Deer Park or a new 1.x release (since that is how
we manage the extension versions and their compatibility)... so perhaps they
need to figure out a way to honor our 1.0 versioning scheme for extensions
compatibility?
*** Bug 300525 has been marked as a duplicate of this bug. ***
install new RF adapter ver 6.3.7, it fixes this bug.

mozilla changes XPCOM calls, so old adapter simply cannot link to FF 1.0.5.

also in new version we improved checking of version numbers,
so now RF adapter should not work on FF versions that it does not support.

i do not know how to make this bug resolved, so knowledgable people shoudl do 
it
Vadim, could you help us out and explain what XPCOM interface or method changed
that caused this crash? We are trying to remain fairly API-stable on the release
branches and it would help us to know what we got wrong.
i will ask programmers to do it in more detail.

the gist of it is that Mozilla/Firefox (unlike IE) do not provide any 
mechanism for run-time linking.

so essentially when they change their API, all offsets there shift and this 
change may be as simple as adding one call.

so as a result, we at RF have to get new sources for new frefox/mozilla and 
recompile the adapter, so that it gets new offsets.

it would be nice if mozilla provided some stable way of run-time linking into 
their code, smth like what IE/MSHTML does with their COM.

We do provide a stable linking mechanism, it is called the XPCOM glue:
http://developer-test.mozilla.org/en/docs/XPCOM_Glue

But I'm still surprised that things changed to cause you breakage between 1.0.x
releases.
Looks like RoboForm now has separate dlls for 1.0.1--1.0.4 and 1.0.5 on their
install page (that's two separate ones; 1.0.5 gets its own).  I've emailed their
technical support asking them for information on what they had to change and
pointing to this bug report...
we will study if this glue mechanism is useable for us.

as to 1.0.5 vs 1.0.4, 
the only change that we did was to recompile adapter so that linking worked.

as to why would mozilla change API enums/offsets, 
that's a good question to be directed at mozilla.
usually 1.0.x releases do not change APIs.

Vadim, there were exactly two api changes on the 1.0.x branch (both of them
mistakes, really), and neither should have caused any problems unless you were
using those specific apis (nsIPrincipal and nsIFileSpec).  Are you, by any chance?
 installed 1.04 then installed roboform then upgraded to 1.05 when ever i 
click on anything get a roboform error mess and firefox crashes 
As I already answered in Roboform techsupport,
=== Cut ===
Roboform Adapter uses unfrozen parts of FireFox, and Mozilla changes them often.

For instance, between 1.0.4 and 1.0.5 there were following changes:

1. Doing mouse click in IHTMLElement proxy (no appropriate call in
nsIDOMHTMLElement):

#if KERNEL_STEPPING < 14 // proir to FireFox 1.0.5
nsMouseEvent event(NS_MOUSE_LEFT_CLICK);
#else // FireFox 1.0.5
nsMouseEvent event(PR_TRUE, NS_MOUSE_LEFT_CLICK, nsnull);
#endif
pContent->HandleDOMEvent(context, &event, nsnull, NS_EVENT_FLAG_INIT, &status);

Here I have coredump each time I send mouse click from Roboform to FireFox
through Adapter.

2. When installing event handler that listens to mouse/key events into
nsIDocument, I need to get nsIContent for clicked element. In most cases, the
event target comes in form of nsIDOMEventRTTearOff class, that has no direct way
to get the nsIContent of the actual event target. So I have to use static type
cast and "access-to-protected-member" hack. In 1.0.5, the implementation if this
class changed, and thus FireFox 1.0.5 with Adapter from 1.0.4 dumps core after
any mouse click in content area.

Don't see any way how to work around it. Using only frozen parts of XPCOM is not
enough for Roboform.
=== Cut ===

Sam, I think I have a couple more questions about what you guys are doing (and
why you're forced to do it that way):

> 1. Doing mouse click in IHTMLElement proxy (no appropriate call in
> nsIDOMHTMLElement):

This looks like it's just dispatching a DOM left-click event, right?  Is there a
reason it couldn't be dispatched as follows:

  nsCOMPtr<nsIDOMDocumentEvent> doc;
  nsresult rv = myDocument->QueryInterface(NS_GET_IID(nsIDOMDocumentEvent),
                                           getter_AddRefs(doc));
  if (NS_FAILED(rv)) return rv;
  nsCOMPTr<nsIDOMEventTarget> target;
  rv = myContentNode->QueryInterface(NS_GET_IID(nsIDOMEventTarget),
                                     getter_AddRefs(target));
  if (NS_FAILED(rv)) return rv;
  nsCOMPtr<nsIDOMEvent> event;
  rv = doc->CreateEvent(NS_LITERAL_STRING("MouseEvents"),
                        getter_AddRefs(event));
  if (NS_FAILED(rv)) return rv;
  nsCOMPTR<nsIDOMMouseEvent> mouseEvent;
  rv = event->QueryInterface(NS_GET_IID(nsIDOMMouseEvent),
                             getter_AddRefs(mouseEvent));
  if (NS_FAILED(rv)) return rv;
  rv = mouseEvent->InitMouseEvent(NS_LITERAL_STRING("click"), PR_TRUE,
                                  PR_TRUE, nsnull, 0, 0, 0, 0, 0, PR_FALSE,
                                  PR_FALSE, PR_FALSE, PR_FALSE, 0, nsnull);
  if (NS_FAILED(rv)) return rv;
  rv = target->DispatchEvent(event);
  if (NS_FAILED(rv)) return rv;

This uses only frozen apis; in fact only APIs well-documented by the DOM2 Events
specification at
<http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/events.html>.

> 2. When installing event handler that listens to mouse/key events into
> nsIDocument, I need to get nsIContent for clicked element. In most cases, the
> event target comes in form of nsIDOMEventRTTearOff class, that has no direct
> way to get the nsIContent of the actual event target.

Assuming that |myTarget| is of type nsDOMEventRTTearOff, the following:

  nsCOMPtr<nsIContent> myContent;
  nsresult rv = myTarget->QueryInterface(NS_GET_IID(nsIContent),
                                         getter_AddRefs(myContent));

this will give you the actual content node, as expected given that QI from IA to
IB and back to IA has to give you the original object...

That said, may I ask what forces you to use nsIContent and nsIDocument in the
first place?  Those interfaces aren't frozen and there are no plans to freeze
them, so if there is functionality that's needed by extension authors that
requires those interfaces we'd like to know so we can put it on other interfaces
(and freeze those).

Thanks for your help!
(In reply to comment #32)
BZ> Sam, I think I have a couple more questions about what you guys are doing
BZ> (and why you're forced to do it that way):

I see :)
Roboform is in fact a Microsoft ActiveX component. Adapter is in fact a
bi-directional DOM translator (something close is made by Adam Lock in
/mozilla/embedding/browser/activex/src/control, but we provide much more decent
translation and the ability to connect to running browser).

S>> 1. Doing mouse click in IHTMLElement proxy (no appropriate call in
S>> nsIDOMHTMLElement):
BZ> This looks like it's just dispatching a DOM left-click event, right?  Is
BZ> there a reason it couldn't be dispatched as follows:
..skip..
No specific reason. I just get the current implementation from mozilla time ago.

S>> 2. When installing event handler that listens to mouse/key events into
S>> nsIDocument, I need to get nsIContent for clicked element. In most cases,
S>> the event target comes in form of nsIDOMEventRTTearOff class, that has
S>> no direct way to get the nsIContent of the actual event target.
BZ> 
BZ> Assuming that |myTarget| is of type nsDOMEventRTTearOff, the following:
BZ> 
BZ> nsCOMPtr<nsIContent> myContent;
BZ> nsresult rv = myTarget->QueryInterface(NS_GET_IID(nsIContent),
BZ>                                        getter_AddRefs(myContent));
BZ> 
BZ> this will give you the actual content node, as expected given that QI
BZ> from IA to IB and back to IA has to give you the original object...
Again, at the time I implemented it for the first time (Mozilla 1.0.1) there
were no such way.

BZ> That said, may I ask what forces you to use nsIContent and nsIDocument in
BZ> the first place?  Those interfaces aren't frozen and there are no plans
BZ> to freeze them, so if there is functionality that's needed by extension
BZ> authors that requires those interfaces we'd like to know so we can put
BZ> it on other interfaces (and freeze those).
No specific reason, as I already said. But there are much more unfrozen
interfaces that I use. Just several examples:

- I need the proxy call for IHTMLElement::get_sourceIndex (which is used to be
zero-based index in document::all collection). Gecko does not provide the
analogue for that, while calculating it on "my side" is time-consuming
procedure. So until now I used isIContent::contentID property as a replacement.

- I need to work with on-screen object coordinates, so I use
nsIScriptGlobalObject (and then presContext etc.). So far I get access
to it like

nsCOMPtr<nsIDocument> pDoc(do_QueryInterface(m_pNative));
if (!pDoc) return E_UNEXPECTED;

#if KERNEL_STEPPING < 7 // Prior to Mozilla 1.6
  pDoc->GetScriptGlobalObject(getter_AddRefs(pGlobal));
#else
  pGlobal = pDoc->GetScriptGlobalObject();
#endif
  if (!pGlobal) return E_UNEXPECTED;

Interfaces are not frozen.

- I work with document selection, but nsISelection is not frozen as well.

I may create a list of methods of unfrozen interfaces that I use, if this will help.

> 
> Thanks for your help!

You did more.
> Again, at the time I implemented it for the first time (Mozilla 1.0.1) there
> were no such way.

I'm sorry, but looking at the Mozilla 1.0.1 source it looks to me like using
QueryInterface in the way I indicated should work just fine there.  See
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/content/base/src/nsGenericElement.cpp&rev=MOZILLA_1_0_1_RELEASE&mark=393,406#392

> No specific reason, as I already said. But there are much more unfrozen
> interfaces that I use.

Sam, note that using unfrozen interfaces does not generally cause problems with
a stable branch, since we try very hard to avoid changing even unfrozen
interfaces on such branches.  The crash issues here arise because concrete
classes were being used... there's really nothing we can do to make that work
smoothly, since we may (and indeed do) need to change concrete classes to handle
security issues.

> #if KERNEL_STEPPING < 7 // Prior to Mozilla 1.6
>   pDoc->GetScriptGlobalObject(getter_AddRefs(pGlobal));
> #else
>   pGlobal = pDoc->GetScriptGlobalObject();
> #endif

Right.  Again, this is something that will work fine on any given stable branch
without causing the sort of problems for users that we're seeing with Firefox 1.0.5.

> I may create a list of methods of unfrozen interfaces that I use, if this will
help.

It would indeed!  Probably worth filing a separate bug on this, and using it to
track freezing of appropriate functionality.  Thanks again!


Sam, here is one thought that might help (might not :-/): pretend Mozilla is not
open source, that you have only certain header files in an SDK, and that you
can't cast your way into the guts of the codebase.  IOW, pretend Gecko is
MSHTML.DLL.

We did not have such as SDK back in the Mozilla 1.0 timeframe, but we've come
part of the way there.  Now is the time for us to provide complete interfaces
for the kind of functionality you need.  RoboForm should work along a stable
branch, if it can avoid fragile C++ dependencies and use XPCOM as it would use
COM with IE.

/be
Just a follow up to my earlier report.  I was on the roboform page and it "says"
it now supports .5.  (I had removed roboform and reinstalled firefox and it
worked fine.  So, I tried installing roboform again.  No luck.  It creates the
same havoc as before... you can not open links.  

So, I removed roboform and that was not enough.  I had to reinstall firefox and
now it works fine. 

Bob 
the problem is created by adapter, not roboform.
so you should upgrade RF Adapter.
uninstalling and reinstalling RoboForm will not change anything.

in the actual truth the problem is created solely by firefox itself,
by their frivolous change of extension APIs and,
to a degree, by lack of official APIs.


Okay, what is an RF adaptor

Bob

If you want to send direct, rcarlson1955@mchsi.com
(In reply to comment #37)
> in the actual truth the problem is created solely by firefox itself,
> by their frivolous change of extension APIs and,
> to a degree, by lack of official APIs.

Vadim, the problem was caused by the adapter's use of non-API concrete classes
in cases where official APIs (some frozen, some regrettably not frozen) with
equivalent functionality existed.  I urge you to talk to Sam about the situation
before making any more false accusations of this sort.

i do not really want to get into the blaming match.

we are trying to imporve integration with firefox 
by using the more frozen API calls that we now know about.

however, in our defense we should say that:

(1) we did not see a document that declared Firefox/Mozilla API for 
developers, something like what MS has in MSDN for MSHTML. We had to get all 
this stuff little by little from source and other places. Is there such a 
document? Maybe we just missed it.

(2) "security updates"  or any minor 1.0.x releases should not break binary 
level API compatibility and they did in 1.0.5.

(3) loosks like it is not only RoboForm that has problem with FF 1.0.5.
I heard that some other extensions do not work with FF 1.0.5.
I also heard that 1.0.6 is to be released soon and that 
the reason for its premature release is fixing bugs created by 1.0.5.
> (1) we did not see a document that declared Firefox/Mozilla API

I'm not completely sure what we have in the way of such documentation.  We're
working on it, but I agree that what we have now is not as slick as MSDN is....

> (2) "security updates"  or any minor 1.0.x releases should not break binary 
> level API compatibility 

Again, part of the problem is that APIs are not what was being used.  Poking
protected members of a concrete class is not API use...

> (3) loosks like it is not only RoboForm that has problem with FF 1.0.5.

Indeed. There were two unfortunate changes to actual APIs in 1.0.5; those
changes are being reverted in 1.0.6, I believe.  Those changes are not what's
causing RoboForm's problems, though, per comment 31.
BTW, http://www.mozilla.org/projects/embedding/ has had Gecko embedding API docs
for years.  They're not complete, and they probably don't give you everything
you need, and they certainly are not MSDN-level quality.  On the other hand,
they are more than you may have known about, so I thought I would mention them.

Vadim: if you didn't use QueryInterface when coding for IE, instead casting
blindly from interface to implementation, then you'd be screwed by concrete
class changes in past IE releases (and probably in IE7).

We have already taken blame for breaking things; that's why we're working hard
on 1.0.6.  We screwed up (twice) in managing the 1.0.x branch conservatively. 
Sorry, again.

But you guys made some mistakes too.  QueryInterface has *always* been supported
(sorry if Sam missed it; it's fundamental to COM and XPCOM).  For you to ignore
the evil-casting-instead-of-querying hacks you guys have done, and escalate the
blame game to put it on our side, makes me not want to cooperate with you.

But I'll go do something else for a while and try not to think that way.

/be
ok, i see that errors were made on both sides.
at least these things have finally come out.

we now will be reviewing all API calls that we use to make sure they 
we use only frozen stuff and use QueryInterface appropriately.

i also propose to take this technical discussion offline,
to the email world, as most readers do not want to go that deep.

finally, if you have any ideas as to how to link to Netscape 8, 
we really need them. Netscape 8 is "closed source" now, but
it looks like they took it a step further and closed APIs too.
and yet a number of users demands support for Netscape 8.

(In reply to comment #42)
> if you didn't use QueryInterface when coding for IE, instead casting
> blindly from interface to implementation, then you'd be screwed by concrete
> class changes in past IE releases (and probably in IE7).
> 
This is the only place in Adapter where I use(d) blind static cast. On the
moment I implemented it, I didn't see required interface among available in MSVS
debugger. In other places - sure, QI is used.

> But you guys made some mistakes too.
Sure.

> QueryInterface has *always* been
> supported (sorry if Sam missed it; it's fundamental to COM and XPCOM).
What else should I say to say I'm sorry?.. Let's go constructive way.
*** Bug 301324 has been marked as a duplicate of this bug. ***
Alias: roboform-crash
*** Bug 301765 has been marked as a duplicate of this bug. ***
this is complete & official way to fix this problem:

Please upgrade RoboForm Adapter to the latest ver 6.3.85 that supports Firefox 
1.0.6 and 1.0.5.
This version fixes exceptions in Firefox and  "Empty toolbar" problem.

This is how to upgrade if you are changing XPI file (say, from Firefox 1.0.4 
to 1.0.5):
- All steps are must-do, if you skip one of them, the whole sequence fails.
- Uninstall 'AI RoboForm Adapter for Firefox/Mozilla/Netscape'
  from 'Control Panel -> Add/Remove Programs,' if you have it there.
- Uninstall 'RoboForm Toolbar Extension' from Firefox's Tools -> Extensions.
  If you have Stumble Upon extension, uninstall it too.
- Close all instances of Firefox and Restart Firefox to make uninstall 
effective.
- Download file http://www.roboform.com/dist/roboform-firefox-1.0.5.xpi
- In Firefox select "File -> Open File", then select the downloaded XPI file.
- Confirm the installation of RoboForm Extension.
- Close all instances of Firefox and Restart Firefox to make XPI install 
effective.

This is how to upgrade if you are upgrading within the same XPI file (say, 
from Firefox 1.0.5 to 1.0.6):
- In Firefox select Tools -> Extensions.
- Select  'RoboForm Toolbar Extension' and click Update button.
- Restart Firefox to make upgraded extension effective.
*** Bug 302077 has been marked as a duplicate of this bug. ***
*** Bug 302312 has been marked as a duplicate of this bug. ***
*** Bug 302329 has been marked as a duplicate of this bug. ***
*** Bug 302312 has been marked as a duplicate of this bug. ***
*** Bug 302417 has been marked as a duplicate of this bug. ***
*** Bug 303015 has been marked as a duplicate of this bug. ***
*** Bug 269514 has been marked as a duplicate of this bug. ***
More about removing unfrozen interfaces in Adapter.

There is a usage of nsIPresContext there. I'd like either to get rig of use it (I only need it to get TwipsToPixels()), or even put this code into Mozilla engine.

The goal of this code is calculation global screen coordinates of any element including nsIDOMText. This is nearly verbatim copy of corresponding code from nsGenericHTMLElement:
=== Cut ===
nsresult CDOMNodeWrapper::GetSizeInfo(nsMargin &aMargin, nsRect &aRect, nsRect &aGlobalRect, float *aP2T, float *aT2P) {
  *aP2T = 0.0f;
  *aT2P = 0.0f;

  nsCOMPtr<nsIDOMDocument> pDOMDoc;
  mNode->GetOwnerDocument(getter_AddRefs(pDOMDoc));
  if (!pDOMDoc) return NS_FAIL;

  nsCOMPtr<nsIDocument> doc(do_QueryInterface(pDOMDoc));
  if (!doc) return NS_OK;

  nsCOMPtr<nsIContent> pContent(do_QueryInterface(m_Node));
  if (!pContent) return NS_FAIL;

  doc->FlushPendingNotifications();

  nsIPresShell *presShell = doc->GetShellAt(0);
  if (!presShell) return NS_OK;

  nsIFrame *frame = nsnull;
  presShell->GetPrimaryFrameFor(pContent, &frame);
  if (!frame) return NS_OK;

  // Get the presentation context
  nsCOMPtr<nsIPresContext> presContext;
  presShell->GetPresContext(getter_AddRefs(presContext));
  if (!presContext) return NS_OK;

  *aP2T = presContext->PixelsToTwips();
  *aT2P = presContext->TwipsToPixels();

  frame->CalcBorderPadding(aMargin);
  aRect = frame->GetRect();

  aGlobalRect = aRect;
  nsRect tempRect;
  frame->GetParent(&frame);
  while (frame) {
    tempRect = frame->GetRect();
    aGlobalRect.x += tempRect.x;
    aGlobalRect.y += tempRect.y;
    frame = frame->GetParent();
  }
  return NS_OK;
}
=== Cut ===
So the only difference from just walking the offsetTop/offsetParent chain and subtracting scrollTop values as needed is that it needs to work for text nodes?

Right.
That should be reasonable.  File a DOM Extensions bug on that?
ok + CC to you.
*** Bug 317325 has been marked as a duplicate of this bug. ***
Closing: since we don't ship the 1.7 branch any more, there's nothing more we can do about it, and everyone seems to have long since wandered off.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
Crash Signature: [@ nsQueryInterface::operator] [@ RoboForm.dll]
You need to log in before you can comment on or make changes to this bug.