762833 - Web apps don't work when Firefox is a XULRunner application

Status: RESOLVED WONTFIX

(Firefox Graveyard :: Webapp Runtime, defect, P3)

Description

[Mike Hommey [:glandium]]

Webapps record the firefox path in webapp.ini, and then tries to load xpcom from there, but in FF-on-XR setups, xpcom is in $firefox_path/xulrunner/.
Changing the path recorded in webapp.ini to point to $firefox_path/xulrunner fails too because the runtime tries to open application.ini there.
It looks like the recorded path should be $firefox_path/xulrunner/, and the runtime should check platform.ini instead of application.ini.

Comment 1

[Mike Hommey [:glandium]]

Attachment: Make webapp runtime use platform.ini from the GRE directory

As a side note, the runtimes would really benefit from using some common init code...

Comment 2

[Mike Hommey [:glandium]]

(In reply to Mike Hommey [:glandium] from comment #1)
> Created attachment 631321 [details] [diff] [review]
> Make webapp runtime use platform.ini from the GRE directory
> 
> As a side note, the runtimes would really benefit from using some common
> init code...

This doesn't work properly, though.

Comment 3

[Mike Hommey [:glandium]]

I'm wondering if it wouldn't make sense to ship the webapprt in xulrunner...

Comment 4

[Jason Smith [:jsmith]]

Should only be FF 15 or later affected, as we have disabled web apps support on FF 14.

Comment 5

[Mike Hommey [:glandium]]

Attachment: Make webapp runtime use platform.ini from the GRE directory

This fixes my problems on FF-on-XR and should help with not breaking things after bug 755724 and I think it's the sensible thing to do. It only addresses the issue on linux, though. It would surely benefit from bug 763071 and bug 658847.
<none>

Comment 6

[Mike Hommey [:glandium]]

Attachment: Fallback to the xulrunner subdirectory if webapprt can't find xpcom in firefox directory

A more lightweight approach.

Comment 7

[Jan Horak [:jhorak]]

Attachment: Workaround to build webapprt also in xulrunner

We hit this problem in Fedora, is it a problem to add webapprt also to xulrunner (like done in attached patch)?

Comment 8

[Mike Hommey [:glandium]]

(In reply to jhorak from comment #7)
> Created attachment 716443 [details] [diff] [review]
> Workaround to build webapprt also in xulrunner
> 
> We hit this problem in Fedora, is it a problem to add webapprt also to
> xulrunner (like done in attached patch)?

webapprt is built as part of browser/ and that should be fine. If that doesn't work (and I heard it doesn't in recent releases in debian, but it used to work), that's a bug.

Comment 9

[Mike Hommey [:glandium]]

Oh, the webapp installer stuff moved to toolkit...

Comment 10

[Mike Hommey [:glandium]]

So, the logical solution here would be to build the webapp runtime as part of the platform. But this would need the webapp runtime localization to move where it should be. I'll file a bug about that.

Comment 11

[Jan Horak [:jhorak]]

I've checked the dependent bugs and they seems to be fixed, can we also fix this bug?

Comment 13

[k]

The problem still persists in Fedora 19. Here's a workaround:
ln -s /usr/lib64/firefox/webapprt-stub /usr/lib64/firefox/xulrunner/
ln -s /usr/lib64/firefox/webapprt /usr/lib64/firefox/xulrunner/
ln -s /usr/lib64/firefox/application.ini /usr/lib64/firefox/xulrunner/

And I can confirm that after doing that, evertything seems to be working ok.

Comment 14

[Marco Castelluccio [:marco]]

Mike, is it now ok to build the webapp runtime also for XULRunner?

Comment 15

[Mike Hommey [:glandium]]

I'd rather put it in the platform as mentioned in comment 10. Either way, the branding problem from i don't remember which bug remains.

Comment 16

[Marco Castelluccio [:marco]]

(In reply to Mike Hommey [:glandium] from comment #15)
> I'd rather put it in the platform as mentioned in comment 10. Either way,
> the branding problem from i don't remember which bug remains.

Yes, the branding problem is a separate issue.

Comment 17

[Mike Hommey [:glandium]]

(In reply to Marco Castelluccio [:marco] from comment #16)
> (In reply to Mike Hommey [:glandium] from comment #15)
> > I'd rather put it in the platform as mentioned in comment 10. Either way,
> > the branding problem from i don't remember which bug remains.
> 
> Yes, the branding problem is a separate issue.

It's not separate, it's entangled.

Comment 18

[Daniele "Mte90" Scasciafratte]

Some reference on Debian and Red Hat

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699294
https://bugzilla.redhat.com/show_bug.cgi?id=912398

Comment 19

[Daniele "Mte90" Scasciafratte]

Any news about this bug?
This create some problems on the linux world for promote the open web apps :-(

Comment 20

[Myk Melez [:myk] [@mykmelez]]

Per bug 1238079, we're going to disable the desktop web runtime and remove it from the codebase, so we won't fix these bugs in it.