![]() given that sometimes declared firefox version does not correspond to the actual version, it may create potentially unfixable crashes. not fixing it in 3.0.2 and fixing it in 3.0.3 makes no sense at all, it will just further confuse the issue, because now we will have 3 different setups to address. So we request and stongly insist that this problem must be fixed in 3.0.2.Ĥ. we really do not like to see our business destroyed, even microsoft - which is an evil corporation - is not evil enough to change binary interfaces in security updates.ģ. by blocking RF or letting it crash you will be effectively destroying our business and not helping your reputation either. we can offer user to upgrade and then user upgrades or not.Ģ. we cannot really "upgrade roboform not to break", not the version that users already have. >take this patch for 3.0.3, the vtable will go back to how it was before 3.0.2ġ. Or you can update RoboForm to not break, I guess, but then when we >We *will* take Roc's patch for Firefox 3.0.3, at which point RoboForm should Please join us in IRC ( #developers) if you need any help. > functionality from "frozen" interfaces. > but we may need assistance from Mozilla developers if we cannot get necessary > we are going to fully convert to "frozen" interfaces for the FF 3.1 release, > any binary addon is much more likely to crash if you do this.Īgreed, which is why it's a good guideline to follow still not guaranteed. First and foremost being that we don't support this as a way of add-ons calling into our code. While I think that's a good general guideline for us to work to, I don't think it's something we can guarantee for reasons that have been expressed to you before. ![]() > vtable indices for dot security releases. > my general proposal is *not* to make any changes that change existing function We are still considering it, but we would like to be able to ship this release sooner rather than later. To do this would add a week to our shipping schedule. > so that RF does not crash and we have time to get rid of offending calls. > can you just keep the order of calls in FF 3.0.2, ![]() Or you can update RoboForm to not break, I guess, but then when we take this patch for 3.0.3, the vtable will go back to how it was before 3.0.2 :( We *will* take Roc's patch for Firefox 3.0.3, at which point RoboForm should work again. I am saying that at this point we are unwilling to delay the release of Firefox 3.0.2 any further, so we will likely be following option #2. Ship Firefox 3.0.2 tomorrow and blocklist the version of RoboForm that crashes. Delay the release of Firefox 3.0.2, take this patch & rebuild.Ģ. > then FF 3.0.3 will work ok with RoboForm?ġ. > do you say FF 3.0.2 will crash or block RF and Vadim: sorry, didn't mean to confuse you. These are public interfaces that shouldn't change in security releases, although they may change between major releases. > *nsIDOMCSS2Properties used to work with CSS > *nsIDOMDocumentXBL used to receive XUL elements (But unlike the previous case, nsIWidget is not potentially public.) Same comment as above about more information being needed. > Roboform requires info about Firefox windows. > *nsIWidget to get handles of firefox windows (for example requires for Basic The frozen DOM event APIs should let you do this. > *nsIMutationObserver to catch DOM tree mutation events You'd need to provide more information about what it is you actually want to do here (although maybe somebody else knows of frozen interfaces for this, or is willing to say that this interface shouldn't change for security releases, which might be the case) - and this bug report probably isn't the best place. > *nsIDocShellTreeItem used to search for HTML docshells ![]() (Public interfaces that shouldn't change for security releases, but might change for major releases - in fact, the two interfaces I pointed you to will be combined in the next major release.) See comment 12 for public interfaces to do this. > *nsIFrame to get html element frame (to get element coordinates) > Examples of using unfrozen interfaces in Roboform: HWND hwnd = (HWND)widget->GetNativeData(NS_NATIVE_WINDOW) Or at least to move GetScreenRectInAppUnitsExternal to the end of nsIFrame definition?įrame = presShell->GetPrimaryFrameFor(pContent) Is it possible to stop Firefox 3.0.2 release and to return back the API? RoboForm uses nsIFrame VFT from Firefox 3.0, and RoboForm call of nsIFrame->GetWindow() causes Firefox to crash.įirefox 3.0.* API shouldn't be changed since Firefox 3.0 release. Virtual method GetScreenRectInAppUnitsExternal has been added. NsIFrame interface has been changed in Firefox 3.0.2.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |