Recent

Author Topic: Status of Gecko SDK Port  (Read 83294 times)

Phil

  • Hero Member
  • *****
  • Posts: 2737
Status of Gecko SDK Port
« on: November 05, 2009, 03:57:09 am »
Because there's been a lot of interest lately in a TWebBrowser-like component for Lazarus, I went ahead and ported Takanori Ito's Gecko SDK for Delphi.

The ported code is here:

http://web.fastermac.net/~MacPgmr/Lazarus/

Download the GeckoPort .zip file, then try installing the GeckoComponents.lpk package and test the two .lpi projects (in SampleApps).

Takanori's SourceForge repository is here:

http://d-gecko.svn.sourceforge.net/viewvc/d-gecko/

I also ported and included the two sample apps from an earlier version of his SDK.

Status report:

***Windows***

Delphi 7: Packages install fine and both sample apps compile and run fine.

Lazarus 0.9.28.2 / FPC 2.2.4: FPC can't compile the TGeckoBrowser component. But the BrowseWin.dpr does not depend on the TGeckoBrowser component and compiles and runs okay.

***OS X / Intel***

Lazarus 0.9.28.2 / FPC 2.2.4: FPC compiles TGeckoBrowser component okay (unlike FPC on Windows). But neither app runs. The InitWindow call to initialize the browser requires a native window to be passed in. A Carbon window won't work since Gecko is expecting a Cocoa NSView (presumably). Since the BrowseWin.dpr app only uses TForm, I tested it with the rudimentary Cocoa widgetset, passing in the TCocoaForm's MainWindowView (declared as NSView), but the app just crashes.

***OS X / PowerPC***

Lazarus 0.9.28.2 / FPC 2.2.4: The code generated by FPC causes an assembler error, something I've never seen before. End of test.


Tasks for those interested in getting TGeckoBrowser working cross-platform:

(1) Test on Windows with more recent compiler builds to see if apparent FPC bug has been fixed.

(2) Test on Linux to see if passing the TGeckoBrowser's or TForm's Handle is the same as passing a GTK window, or whether the window pointer has to be obtained indirectly from the widgetset controls as with Carbon and Cocoa.

On Linux you may need to change the code to specify the correct path to libxpcom.so. See XRE_FindGRE in nsXRE.pas and GetGREDirectoryPath in nsInit.pas.

(3) Takanori's Delphi code for determining the location of installed Gecko libraries does not find Firefox 3.5's DLL's on Windows, so for now I just hardwired the location in the code. Someone could test to see whether an installation of XULRunner sets the registry the way the code expects. Versions of XULRunner for all platforms are here:

https://developer.mozilla.org/en/XULRunner

On OS X, this installs XUL.framework under /Library/Frameworks.

Note that on OS X, I launched the test apps from a script (included) in order to set the DYLD_LIBRARY_PATH variable to point to XUL.framework. I also tested it against the Gecko libraries included in /Applications/Firefox.app.

Please report your results here.

Thanks.

-Phil

alter

  • Full Member
  • ***
  • Posts: 151
    • KSP website
Re: Status of Gecko SDK Port
« Reply #1 on: November 05, 2009, 04:19:52 am »
Going to look morning how it works with Linux. Does it support html editing? It's 4 am here so I didn't have much time to look into it:-)

Edit:
line 180 of nsXRE: I added xpcomPath:=ExtractFilePath(Application.ExeName)+'xulrunner\xpcom.dll'; and deleted NS_StrLCopy. Now doesn't depend on any paths in Program Files (just put Gecko in xulrunner subfolder)
« Last Edit: November 05, 2009, 02:48:17 pm by alter »

thierrybo

  • Full Member
  • ***
  • Posts: 143
Re: Status of Gecko SDK Port
« Reply #2 on: November 05, 2009, 03:27:30 pm »
I installed Lazarus 0.9.28-2 satble version on windows XP (no previuos lazarus installation).

I have these messages :
Quote
...\GeckoBrowser.pas(455,14) Error: There is no method in an ancestor class to be overridden: "TGeckoBrowserChrome.GetChromeFlags:DWord;"
...\GeckoBrowser.pas(460,14) Error: There is no method in an ancestor class to be overridden: "TGeckoBrowserChrome.IsWindowModal:LongBool;"
...\GeckoBrowser.pas(469,14) Error: There is no method in an ancestor class to be overridden: "TGeckoBrowserChrome.GetVisibility:LongBool;"
...\GeckoBrowser.pas(471,14) Error: There is no method in an ancestor class to be overridden: "TGeckoBrowserChrome.GetTitle:^WideChar;"
...\GeckoBrowser.pas(473,14) Error: There is no method in an ancestor class to be overridden: "TGeckoBrowserChrome.GetSiteWindow:^untyped;"

Phil

  • Hero Member
  • *****
  • Posts: 2737
Re: Status of Gecko SDK Port
« Reply #3 on: November 05, 2009, 03:34:03 pm »
Yes, those are the same errors I get with FPC 2.2.4 on Windows. I think that might be an FPC bug since this component compiles okay on OS X with FPC 2.2.4.

As I suggested, perhaps you could test with FPC 2.3.1.

Thanks.

-Phil

thierrybo

  • Full Member
  • ***
  • Posts: 143
Re: Status of Gecko SDK Port
« Reply #4 on: November 05, 2009, 04:11:40 pm »
By the way it compiles fine if I add
Code: [Select]
safecall to theses procedures.

Phil

  • Hero Member
  • *****
  • Posts: 2737
Re: Status of Gecko SDK Port
« Reply #5 on: November 05, 2009, 04:30:41 pm »
You're a genius, although I don't understand why that would be necessary since it's not needed to compile on OS X.

I'm getting a crash now with GBrowser.dpr app, but if I comment out this line in TCustomGeckoBrowser.InitWebBrowser, it will run.

//    FListeners.InitListener(Self);

I'm getting some range checking errors, but at least the browser window comes up now!

Now we just have to get it to work on Linux and OS X.

Thanks.

-Phil

alter

  • Full Member
  • ***
  • Posts: 151
    • KSP website
Re: Status of Gecko SDK Port
« Reply #6 on: November 05, 2009, 04:59:56 pm »
I disabled range checking in compiler options and it runs smoothly

Phil

  • Hero Member
  • *****
  • Posts: 2737
Re: Status of Gecko SDK Port
« Reply #7 on: November 05, 2009, 05:03:39 pm »
Right, although you're likely just covering up a bug doing that.

Have you tested on Linux?

Thanks.

-Phil

alter

  • Full Member
  • ***
  • Posts: 151
    • KSP website
Re: Status of Gecko SDK Port
« Reply #8 on: November 05, 2009, 05:10:42 pm »
Right, although you're likely just covering up a bug doing that.

Have you tested on Linux?

Thanks.

-Phil

Not yet. I think it's better to make it first for Windows then I will check how it works with Linux.
I did this:

Code: [Select]
{$R-}
      browser.AddWebBrowserListener(weak, table.Entries[i].IID^);
{$R+}

around line 880 and

Code: [Select]
{$R-}
      browser.RemoveWebBrowserListener(weak, table.Entries[i].IID^);
{$R+}


around line 900. Those 2 lines are faulty. Now If I enable range checking in compiler options then page is loaded but still each few seconds I get out of range error.

Edit:

around line 1600:

Code: [Select]
{$R-}
    Result := QueryInterface(uuid, _result);
{$R+}
and control works (no errors at least)
« Last Edit: November 05, 2009, 05:22:49 pm by alter »

alter

  • Full Member
  • ***
  • Posts: 151
    • KSP website
Re: Status of Gecko SDK Port
« Reply #9 on: November 05, 2009, 05:24:31 pm »
In GeckoChromeWindow around 376:

Code: [Select]
{$R-}
    Result := QueryInterface(uuid, Intf);
{$R+}  
Looks like those problems may be caused not by faulty pascal code but problems with Xulrunner itself since when I changed code above program responded as it should

Another problem appeared:
When I have only one TGeckoBrowser object then it is ok but when I create second one then whenever this second one tried to load some url i get sigsegv at line 1097 in GeckoBrowser unit (line: nav.LoadURI(PWideChar(uri), Flags, referer, post, head);)
« Last Edit: November 05, 2009, 09:17:51 pm by alter »

Phil

  • Hero Member
  • *****
  • Posts: 2737
Re: Status of Gecko SDK Port
« Reply #10 on: November 06, 2009, 04:12:00 am »
I've uploaded an updated GeckoPort .zip:

http://web.fastermac.net/~MacPgmr/Lazarus/

This fixes a few things:

- GeckoComponents.lpk now compiles and installs in Lazarus okay on Windows.

- GBrowser.dpr sample app doesn't crash at startup - still has some range-check errors, though. Compile with range checking off or use Alter's suggestions above until I can track down and eliminate these bugs.

- BrowseWin.dpr sample app now starts okay on OS X and loads Lazarus Web site. Here's what I did:
  -- Installed xulrunner-1.9.1.4.en-US.mac-pkg.dmg
  -- Compiled against Cocoa widgetset:
       lazbuild -B --ws=cocoa browsewin.lpi
You can also compile from Lazarus if you change the widgetset to Cocoa. Note that the Cocoa widgetset is not supplied already compiled with Lazarus the way Carbon is. See Lazarus wiki for instructions on how to compile the Cocoa widgetset against PasCocoa.
  -- Ran it with supplied script:  ./run-bw-mac.sh

- GBrowser.dpr sample app still crashes on OS X, but not because of Gecko anymore. It appears as though TCustomControl (from which TGeckoBrowser is descended) is not supported yet in the Cocoa widgetset.

Thanks.

-Phil

MvC

  • New Member
  • *
  • Posts: 25
    • Free Pascal Core team member
Re: Status of Gecko SDK Port
« Reply #11 on: November 06, 2009, 09:14:32 am »
The reason this is needed is because all ActiveX interfaces must use the SafeCall
calling conventions. On systems other than Windows, SafeCall is equal to the
default calling convention, so you don't get an error...

You're a genius, although I don't understand why that would be necessary since it's not needed to compile on OS X.

I'm getting a crash now with GBrowser.dpr app, but if I comment out this line in TCustomGeckoBrowser.InitWebBrowser, it will run.

//    FListeners.InitListener(Self);

I'm getting some range checking errors, but at least the browser window comes up now!

Now we just have to get it to work on Linux and OS X.

Thanks.

-Phil


MvC

  • New Member
  • *
  • Posts: 25
    • Free Pascal Core team member
Re: Status of Gecko SDK Port
« Reply #12 on: November 06, 2009, 10:25:54 am »
Hi,

I made 2 small changes so it compiles on Linux 64-bit.
Is yours code checked-in somewhere in a version system so I can
create some diffs or how do I communicate changes ?

I think that this component is so important that it should actually be
distributed with Lazarus; It may be a good idea to ask if it can be
committed in their components directory. If you get write permission on
this directory, you can do the maintenance yourself.

If that's not possible/allowed, I suggest trying lazarus-ccr.

malcome

  • Jr. Member
  • **
  • Posts: 80
Re: Status of Gecko SDK Port
« Reply #13 on: November 06, 2009, 11:28:33 pm »

Phil

  • Hero Member
  • *****
  • Posts: 2737
Re: Status of Gecko SDK Port
« Reply #14 on: November 07, 2009, 12:21:07 am »

I did this:

Code: [Select]
{$R-}
      browser.AddWebBrowserListener(weak, table.Entries[i].IID^);
{$R+}

around line 880 and

Code: [Select]
{$R-}
      browser.RemoveWebBrowserListener(weak, table.Entries[i].IID^);
{$R+}


around line 900. Those 2 lines are faulty. Now If I enable range checking in compiler options then page is loaded but still each few seconds I get out of range error.

This is an FPC bug. Entries is only declared Array[0..0] so of course it throws a range check error if there's more than 1 entry in the table. Delphi more sensibly declares Entries as array[0..9999]. I guess the FPC guys assume we always work with interfaces with range checking turned off.

I changed the code to this:

 {$IFOPT R+}{$DEFINE TURNED_RANGE_CHECK_OFF}{$R-}{$ENDIF}
      browser.AddWebBrowserListener(weak, table.Entries.IID^);
 {$IFDEF TURNED_RANGE_CHECK_OFF}{$UNDEFINE TURNED_RANGE_CHECK_OFF}{$R+}{$ENDIF}


Quote
around line 1600:

Code: [Select]
{$R-}
    Result := QueryInterface(uuid, _result);
{$R+}
and control works (no errors at least)

This is also an odd one. QueryInterface returns LongInt, but Result is LongWord, so anytime result returned is negative we get a range-check error. However, if negative, that means the severity bit is set, which presumably means something is wrong. So my change may only be covering up something else:

    Result := nsresult(QueryInterface(uuid, _result));

 

TinyPortal © 2005-2018