Last Comment Bug 762833 - Web apps don't work when Firefox is a XULRunner application
: Web apps don't work when Firefox is a XULRunner application
Status: RESOLVED WONTFIX
:
Product: Firefox Graveyard
Classification: Graveyard
Component: Webapp Runtime (show other bugs)
: 14 Branch
: x86_64 Linux
P3 normal
: ---
Assigned To: Mike Hommey [:glandium]
: Jason Smith [:jsmith]
:
Mentors:
: 913741 (view as bug list)
Depends on: 844016
Blocks: 745018 1111077
  Show dependency treegraph
 
Reported: 2012-06-08 02:19 PDT by Mike Hommey [:glandium]
Modified: 2017-08-11 05:17 PDT (History)
11 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Make webapp runtime use platform.ini from the GRE directory (7.80 KB, patch)
2012-06-08 02:41 PDT, Mike Hommey [:glandium]
no flags Details | Diff | Splinter Review
Make webapp runtime use platform.ini from the GRE directory (4.32 KB, patch)
2012-06-09 00:18 PDT, Mike Hommey [:glandium]
no flags Details | Diff | Splinter Review
Fallback to the xulrunner subdirectory if webapprt can't find xpcom in firefox directory (2.04 KB, patch)
2012-10-04 23:55 PDT, Mike Hommey [:glandium]
no flags Details | Diff | Splinter Review
Workaround to build webapprt also in xulrunner (475 bytes, patch)
2013-02-21 02:34 PST, Jan Horak
no flags Details | Diff | Splinter Review

Description User image Mike Hommey [:glandium] 2012-06-08 02:19:50 PDT
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 User image Mike Hommey [:glandium] 2012-06-08 02:41:11 PDT
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...
Comment 2 User image Mike Hommey [:glandium] 2012-06-08 03:22:40 PDT
(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 User image Mike Hommey [:glandium] 2012-06-08 03:30:08 PDT
I'm wondering if it wouldn't make sense to ship the webapprt in xulrunner...
Comment 4 User image Jason Smith [:jsmith] 2012-06-08 08:12:13 PDT
Should only be FF 15 or later affected, as we have disabled web apps support on FF 14.
Comment 5 User image Mike Hommey [:glandium] 2012-06-09 00:18:05 PDT
Created attachment 631623 [details] [diff] [review]
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 User image Mike Hommey [:glandium] 2012-10-04 23:55:19 PDT
Created attachment 668346 [details] [diff] [review]
Fallback to the xulrunner subdirectory if webapprt can't find xpcom in firefox directory

A more lightweight approach.
Comment 7 User image Jan Horak 2013-02-21 02:34:22 PST
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)?
Comment 8 User image Mike Hommey [:glandium] 2013-02-21 02:42:31 PST
(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 User image Mike Hommey [:glandium] 2013-02-22 01:17:31 PST
Oh, the webapp installer stuff moved to toolkit...
Comment 10 User image Mike Hommey [:glandium] 2013-02-22 01:59:23 PST
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 User image Jan Horak 2013-07-02 22:50:29 PDT
I've checked the dependent bugs and they seems to be fixed, can we also fix this bug?
Comment 12 User image Marco Castelluccio [:marco] (PTO) 2013-09-10 12:15:18 PDT
*** Bug 913741 has been marked as a duplicate of this bug. ***
Comment 13 User image k 2013-09-10 12:45:34 PDT
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 User image Marco Castelluccio [:marco] (PTO) 2013-09-20 18:08:50 PDT
Mike, is it now ok to build the webapp runtime also for XULRunner?
Comment 15 User image Mike Hommey [:glandium] 2013-09-20 18:25:32 PDT
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 User image Marco Castelluccio [:marco] (PTO) 2013-09-23 16:55:00 PDT
(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 User image Mike Hommey [:glandium] 2013-09-23 18:26:21 PDT
(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 User image Daniele "Mte90" Scasciafratte 2014-05-11 12:53:31 PDT
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 User image Daniele "Mte90" Scasciafratte 2014-05-17 03:30:11 PDT
Any news about this bug?
This create some problems on the linux world for promote the open web apps :-(
Comment 20 User image Myk Melez [:myk] [@mykmelez] 2016-01-25 13:42:54 PST
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.

Note You need to log in before you can comment on or make changes to this bug.