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

RESOLVED WONTFIX

Status

Firefox Graveyard
Webapp Runtime
P3
normal
RESOLVED WONTFIX
5 years ago
a year ago

People

(Reporter: glandium, Assigned: glandium)

Tracking

14 Branch
x86_64
Linux
Dependency tree / graph

Details

Attachments

(2 attachments, 2 obsolete attachments)

(Assignee)

Description

5 years ago
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.
(Assignee)

Updated

5 years ago
Blocks: 745018
(Assignee)

Comment 1

5 years ago
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...
(Assignee)

Updated

5 years ago
Blocks: 755724
(Assignee)

Comment 2

5 years ago
(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.
(Assignee)

Comment 3

5 years ago
I'm wondering if it wouldn't make sense to ship the webapprt in xulrunner...
(Assignee)

Updated

5 years ago
Component: Web Apps → Webapp Runtime
QA Contact: webapps → webapp-runtime
(Assignee)

Updated

5 years ago
status-firefox14: --- → affected
status-firefox15: --- → affected
Should only be FF 15 or later affected, as we have disabled web apps support on FF 14.
status-firefox14: affected → ---
Priority: -- → P3
(Assignee)

Comment 5

5 years ago
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>
(Assignee)

Updated

5 years ago
Attachment #631321 - Attachment is obsolete: true

Updated

5 years ago
QA Contact: jsmith

Updated

5 years ago
status-firefox15: affected → ---
status-firefox16: --- → wontfix
(Assignee)

Comment 6

5 years ago
Created attachment 668346 [details] [diff] [review]
Fallback to the xulrunner subdirectory if webapprt can't find xpcom in firefox directory

A more lightweight approach.
(Assignee)

Updated

5 years ago
Attachment #631623 - Attachment is obsolete: true
(Assignee)

Updated

5 years ago
Assignee: nobody → mh+mozilla
(Assignee)

Updated

5 years ago
No longer blocks: 755724

Comment 7

4 years ago
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)?
(Assignee)

Comment 8

4 years ago
(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.
(Assignee)

Comment 9

4 years ago
Oh, the webapp installer stuff moved to toolkit...
(Assignee)

Comment 10

4 years ago
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.
(Assignee)

Updated

4 years ago
Depends on: 844016

Comment 11

4 years ago
I've checked the dependent bugs and they seems to be fixed, can we also fix this bug?
Duplicate of this bug: 913741

Comment 13

4 years ago
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.
Flags: needinfo?(mh+mozilla)
Mike, is it now ok to build the webapp runtime also for XULRunner?
(Assignee)

Comment 15

4 years ago
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.
Flags: needinfo?(mh+mozilla)
(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.
(Assignee)

Comment 17

4 years ago
(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.
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
Any news about this bug?
This create some problems on the linux world for promote the open web apps :-(
Blocks: 1111077
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.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → WONTFIX
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.