Prism extension not working on Firefox (-app flag)

Bug #241787 reported by mitch
56
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Fix Released
High
firefox-3.0 (Ubuntu)
Won't Fix
Medium
Unassigned
firefox-3.5 (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

Binary package hint: Firefox

Ubuntu 8.04
Firefox 3

After using the extension Prism to create a desktop shortcut, clicking on the shortcut should open a Prism style window.

Instead clicking on the shortcut opened a normal Firefox browser showing the home page.

Using Prism extension 0.2

This bug was reported to Mozilla and the bug report says that there may be a "build configuration issue" with Ubuntu's Firefox and that the -app flag may not not working properly.
Bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=436998

Revision history for this message
In , Onestone (onestone) wrote :

I confirm this bug. The Prism Extension v0.2 is practically unusable on Linux because of it. I have FF 3 Beta 5 on Ubuntu 8.04.

Revision history for this message
In , Dan Dillinger (yazirian) wrote :

This appears to be an issue related to the -app argument somehow simply not working. I first noticed it when trying to use firefox instead of xulrunner to start a xul application:

http://developer.mozilla.org/en/docs/XULRunner_tips#Using_Firefox_3_to_run_XULRunner_applications

I followed those instructions, and instead of opening my app window (as xulrunner would), I found that firefox simply loaded its usual window and start page.

Then, upon starting a Prism shortcut (to gmail), it exhibited the same behavior -- I got the default firefox window and start page instead.

I am also running Firefox 3 on Ubuntu 8.04

Revision history for this message
In , Mark-finkle (mark-finkle) wrote :

Can someone install a Mozilla build of Firefox 3 to see if there is a build configuration issue?

Revision history for this message
In , Dan Dillinger (yazirian) wrote :

Installed 3.0rc2 from http://www.mozilla.com/en-US/firefox/all-beta.html

Problem does not exist, -app flag starts up the expected xul application.

Revision history for this message
mitch (mitch-lloyd) wrote : Prism extension not working on ubufox (-app flag)

Binary package hint: ubufox

Ubuntu 8.04
Ubufox 0.5-0ubuntu1

After using the extension Prism to create a desktop shortcut, clicking on the shortcut should open a Prism style window.

Instead clicking on the shortcut opened a normal Firefox browser showing the home page.

Using Prism extension 0.2

This bug was reported to Mozilla and they determined that there was a "build configuration issue" with Ubuntu's Firefox and that the -app flag was not working properly.
Bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=436998

description: updated
mitch (mitch-lloyd)
description: updated
description: updated
Revision history for this message
In , Matthew-gertner (matthew-gertner) wrote :

So this bug is invalid, right?

Revision history for this message
In , Ron-atomeo (ron-atomeo) wrote :

Most likely but I'm not sure, as it depends on what the Ubuntu developers have to say.

For more information see: https://bugs.launchpad.net/ubuntu/+source/ubufox/+bug/241787

Revision history for this message
Ronald Schouten (atomicron) wrote :

I just wanted to confirm that I am experiencing this problem. Although, it is possible to work around this issue by using the stand alone version of prism from the repository, this is sub-optimal since it forces the user to use an older version of the app.

Revision history for this message
In , Alexander Sack (asac) wrote :

This bug happens on all --with-libxul-sdk builds of firefox. Point is that the firefox binary (aka xulrunner-stub) doesnt provide a fully fledged xulrunner command line interface.

Revision history for this message
Alexander Sack (asac) wrote :

is this problem really introduced by ubufox? Moving to ffox 3 for now.

Changed in ubufox:
status: New → Incomplete
Revision history for this message
Ronald Schouten (atomicron) wrote :

I would say that it is caused by Ubufox. Downloading the version of Firefox 3 for Linux from Mozilla does not have this problem.

Revision history for this message
In , Pelzowski (pelzowski) wrote :

I can confirm this bug on openSUSE 11.0 KDE4. Firefox version shiped with distribution: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.0) Gecko/2008061600 SUSE/3.0-0.2 Firefox/3.0

Clicking on short cut made by "Prism for Firefox" executes firefox homepage. It is not fixed also in Prism for Firefox 0.9.1 (Experimental) [ refractor-linux.xpi ]

However Prism works as an standalone app, not as addon, as expected. (Prism 0.9.1 can by found here http://browsing.justdiscourse.com/2008/07/10/mozilla-prism-091-experimental-now-available/ )

Revision history for this message
In , Pelzowski (pelzowski) wrote :

Oh, I forgot. From #Prism IRC Conversation: "need to fix stub, it doesn't handle the -app flag. firefox -app doesn't work on Linux"

Revision history for this message
Ronald Schouten (atomicron) wrote :

Not to add confusion, but it looks like the version of Firefox that ships with openSUSE 11.0 KDE4 also has the same problem [https://bugzilla.mozilla.org/show_bug.cgi?id=436998].

Revision history for this message
John Vivirito (gnomefreak) wrote : Re: [Bug 241787] Re: Prism extension not working on Firefox (-app flag)

Ronald Schouten wrote:
> Not to add confusion, but it looks like the version of Firefox that
> ships with openSUSE 11.0 KDE4 also has the same problem
> [https://bugzilla.mozilla.org/show_bug.cgi?id=436998].
>
>
The extension has been changed to a separate package a stand alone
browser. See prism apt-cache show prism here is oputput

Prism, previously called WebRunner, is a simple XULRunner based browser that
 hosts web applications without the normal web browser user interface. It is
 based on a concept called Site Specific Browsers (SSB).
--------------------------------------------------------------------------------------------------------
No longer an extension it is in Ubuntu repos as for Suse or anyone else
other than debian and us im not sure about but you should push to get it
included if you really want it say in suse or the or fedora ect...
I would say as work around until the fix is released to use standalone.
I like it atleast.
Ronald,
we dont really need to track other bugs since upstream bug is being
worked on

--
Sincerely Yours,
    John Vivirito

https://launchpad.net/~gnomefreak
https://wiki.ubuntu.com/JohnVivirito
Linux User# 414246

Changed in firefox:
status: Unknown → Confirmed
Revision history for this message
In , Ron-atomeo (ron-atomeo) wrote :

Between Alexander's and Piotr's comments I'm not sure where the fix is. Can someone in the know make a clear comment on this issue?

Revision history for this message
In , Mark-finkle (mark-finkle) wrote :

Some Linux distros use Firefox-on-XULRunner. Which means that the firefox binary is actually the xulrunner-stub. The xulrunner-stub doesn't have the commandline handler for the -app flag.

The fix should be to add the handler to the xulrunner-stub.

What do you think, Benjamin?

Revision history for this message
In , Benjamin Smedberg (Mozilla) [:bs] (benjamin-smedbergs) wrote :

That's acceptable.

Revision history for this message
In , Mark-finkle (mark-finkle) wrote :

Thinking more about this, changing xulrunner-stub is _not_ the right answer. Realize that "firefox -app" means "let this xulapp use the libxul runtime that powers firefox" and, further, firefox-on-xulrunner doesn't have a libxul of it's own.

Therefore, we should try to fix this bug by _not_ using "firefox -app" when Friefox has no libxul, but instead use the XULRunner runtime that Firefox itself is using.

Using "XpcomLib" or "GreD" could get us the path to the xulrunner runtime.

Revision history for this message
In , Matthew-gertner (matthew-gertner) wrote :

*** Bug 432433 has been marked as a duplicate of this bug. ***

Revision history for this message
m45smg (m45smg) wrote :

I have this problem too.
I installed the prism in my FireFox. Then make "http://www.runescape.com/" in web app on my desktop. When I open it is "http://hk.yahoo.com/ (my homepage)".

OS: Ubuntu 8.04.1
Kernel: 2.6.24.21
FireFox: 3.0.1

Revision history for this message
In , Olivier Bilodeau (plaxx) wrote :

The problem is because the firefox binary on ubuntu (and Suse I guess) doesn't accept the -app parameter.

Now this link[1] says that under linux you should use the xulrunner binary instead of the firefox binary to launch XULRunner applications.

So, in order to fix this, shouldn't the plugin create the link using the firefox binary for windows and using the xulrunner one for linux?

[1] https://developer.mozilla.org/en/XULRunner_tips#Using_Firefox_3_to_run_XULRunner_applications

Revision history for this message
Olivier Bilodeau (plaxx) wrote :

I am experiencing the same exact problem in Intrepid.

Ubuntu 8.10 Intrepid Ibex
Firefox 3.0.3+nobinonly-0ubuntu2

The problem seems to be related to the fact that the firefox binary in ubuntu doesn't interpret the command line parameter --app but the typical prism launcher uses it.

olivier@boreale:~$ /usr/lib/firefox-3.0.3/firefox --help
Usage: /usr/lib/firefox-3.0.3/firefox [ options ... ] [URL]
       where options include:

X11 options
 --display=DISPLAY X display to use
 --sync Make X calls synchronous
 --no-xshm Don't use X shared memory extension
 --xim-preedit=STYLE
 --xim-status=STYLE
 --g-fatal-warnings Make all warnings fatal

Mozilla options
 -height <value> Set height of startup window to <value>.
 -h or -help Print this message.
 -width <value> Set width of startup window to <value>.
 -v or -version Print Firefox version.
 -P <profile> Start with <profile>.
 -ProfileManager Start with ProfileManager.
 -no-remote Open new instance, not a new window in running instance.
 -UILocale <locale> Start with <locale> resources as UI Locale.
 -safe-mode Disables extensions and themes for this session.
  -jsconsole Open the Error console.

No --app there. But if you look at the launcher:
"/usr/lib/firefox-3.0.3/firefox" -app "/home/olivier/.mozilla/firefox/<censored>/<email address hidden>/prism/application.ini" -override "/<email address hidden>/override.ini" -webapp <email address hidden>

Workaround:
xulrunner does take the --app parameter so I changed the "/usr/lib/firefox-3.0.3/firefox" from the launcher to /usr/bin/xulrunner and it worked! Yay!

Now, why is ubuntu's firefox not taking --app?

Revision history for this message
In , Alexander Sack (asac) wrote :

Starting from comment 13 we could go further and provide a |XulAppCmd| that would allow extensions to gather the right xulrunner compatible command in a transparent fashion.

For example, when firefox is build --with-libxul-sdk it would point to $gre_dir/xulrunner ... otherwise $appdir/$appname.

Revision history for this message
In , Matthew-gertner (matthew-gertner) wrote :

I'm happy to go with Mark's approach (i.e. using the shared XULRunner). Furthermore I would be delighted if someone with a Linux focus were willing to take a crack at this. I'm proposing it as blocking to Prism 1.0 and we want to get that out ASAP. Mark and I both have tons of work for 1.0 already. Come on Linux people, let's make Prism great on Linux as well!

Changed in firefox-3.0:
status: Incomplete → Triaged
Revision history for this message
In , Matthew-gertner (matthew-gertner) wrote :

*** Bug 476322 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Tonikitoo (tonikitoo) wrote :

*finally* working effectively on it.

approach: trying to make xulrunner-stup to support -app ... as per mark suggestion on irc.

uploading a patch soon.

Changed in firefox:
status: Confirmed → In Progress
Revision history for this message
In , Tonikitoo (tonikitoo) wrote :

Created an attachment (id=366583)
patch 0.1 - add -app support to xulrunner-stub (WIP)

First working version on linux. It has some issues I am trying to fix/improve, but the core of the idea would be it.

It works fine on Linux, I will test on other platforms (I have only WinXP soon).

@Mark:

1) should we change bug title to reflect to what the fix really is ?

2) is that the right approach ? (keep in mind if it looks hacky it is because i started yesterday at around 11:47 PM :))

Revision history for this message
In , Tonikitoo (tonikitoo) wrote :

Created an attachment (id=366590)
patch 0.2 - add -app support to xulrunner-stub

same patch as previous 0.1, but functional.

Revision history for this message
In , Tonikitoo (tonikitoo) wrote :

Created an attachment (id=367490)
patch 0.21 - add -app support to xulrunner-stub

same patch as 0.2 but making changes ifdef'ed to XP_UNIX.

Revision history for this message
In , Tonikitoo (tonikitoo) wrote :

so patch works fine if launching:

1) from xulrunner-stub itself (in .../browser/dist/bin/xulrunner)

$ ./xulrunner-stub -app /<email address hidden>/prism/application.ini -override /<email address hidden>/override.ini -webapp <email address hidden>

2) from firefox-xulrunner-stub (in .../browser/dist/bin/)

/firefox -app /<email address hidden>/prism/application.ini -override /<email address hidden>/override.ini -webapp <email address hidden>

3) from clicking the webapp icon (e.g. in ~/Desktop)

Exec="/home/agomes/mozilla/objdir/browser/dist/bin/firefox" -app "/home/agomes/.mozilla/firefox/uu0nc5ri.prism/extensions/refracto
<email address hidden>/prism/application.ini" -override "/<email address hidden>/override.ini" -webapp <email address hidden>

one thing that has to be pointed out is:

1) patch does add support for "-app" parameter only, so other ones that show up above , including "-override" and "-webapp" are being ignored by the stub.

Revision history for this message
In , Mark-finkle (mark-finkle) wrote :

(From update of attachment 367490)
Overall, this looks pretty good. One thing I would like to do is move the "--app" out of the Linux-only block and make it available for all platforms.

We already have a use for this in Fennec (Windows Mobile).

Revision history for this message
In , Tonikitoo (tonikitoo) wrote :

Created an attachment (id=368827)
patch 0.3 - add -app support to xulrunner-stub

same patch as 0.21 but not ifdef'ed to Linux.

highlights:

* I have not tested it on Win32/CE or MAC, but on linux only. I suppose these are the platforms to be considered here (?).

* the Mac change has to be reviewed and tested. I can test on windows.

* my bigger concern: scenario

0) pre-conditions:
- patch is applied (xulrunner stub supports -app parameter).
- user has prism addon installed.
1) user goes to any website (www.xyz.ab) and make a webapp off of it.
2) user does not close FF, and try to run the webapp by clicking on the Prism Icon generated on desktop. Although "-app" is supported, it will keep opening a FF window, as if user has one firefox opened and type 'firefox' again in the terminal (just a new window is created not another instance of Firefox on its own process).

if we close firefox xulrunner_stub + "-app" works fine.

Mark, ^

Revision history for this message
In , Tonikitoo (tonikitoo) wrote :

as bug scope is now bigger than original goal, I am changing it accordingly.

was: "prism extension creates desktop launcher but opens firefox".

Revision history for this message
In , Tonikitoo (tonikitoo) wrote :

(From update of attachment 368827)
as per discussed on IRC:

1) wince does not work w/ this. Brad helped me to fix this.

2) there should be no link to nspr in stub.

3) this stub will need a more robust way to find the greDir.

new patch coming...

Revision history for this message
In , Tonikitoo (tonikitoo) wrote :

Created an attachment (id=369827)
patch 0.4 - add -app support to xulrunner-stub

Revision history for this message
In , Tonikitoo (tonikitoo) wrote :

(From update of attachment 369827)
* patch removes NSPR dep introduced in previous patch. It is wrong according to GRE docs.

Open questions:

-> @mfinkle: we find GRE in two ways here:

1) looks for a xulrunner dir in the same folder of application.in
2) find the xulrunner dir installed/registered in the system through GRE_GetGREPathWithProperties call

what can be improved ?

-> need brad (or some other wince lover) to test on that platform.

Revision history for this message
In , Tonikitoo (tonikitoo) wrote :

Created an attachment (id=370647)
patch 0.5 - add -app support to xulrunner-stub

as per irc discussion, patch 0.5 now postpones the use of -app parameter (if passed in) to after greDir initial checks.

Reason: it is desired to keep the current way of looking for the greDir, avoiding making it relative to the specified application.ini path.

ps: tested on linux only so far.

Revision history for this message
In , Mark-finkle (mark-finkle) wrote :

(From update of attachment 370647)

>+static nsresult SetEnvironmentVariable(const char* aEnvVar, const char* aValue)

I worry about this function name since it is the same as a #define in the windows headers. Could we rename to | SetEnv | ?

>+
>+/**
>+ * Return true if |greDir| is a valid GRE directory.

   * Return true if a given folder exists.

(this function is not limited to gre folders)

>+ */
>+static PRBool FolderExists(const char* greDir)

const char* aDir

>+{
>+#ifdef WINCE
>+ wchar_t wideGreDir[MAX_PATH];

wchar_t wideDir[MAX_PATH];

>+#else
>+ return access(greDir, R_OK) == 0;
>+#endif
>+
>+ return 0;

This | return 0; | is not needed. The #else handles it.

>+}
>+
>+static const char* GetRealPath(const char* appDataFile)
>+{
>+ char result[MAXPATHLEN];

I guess the the static function makes the data inside static too. I was a little worried the buffer was being freed when the function returned.

r=me with these comments addressed

Revision history for this message
In , Bugmail-lassey (bugmail-lassey) wrote :

shouldn't the functionality of SetEnvironmentVariable be provided by PR_SetEnv? If not, lets fix PR_SetEnv.

Revision history for this message
In , Tonikitoo (tonikitoo) wrote :

(In reply to comment #32)
> shouldn't the functionality of SetEnvironmentVariable be provided by PR_SetEnv?
> If not, lets fix PR_SetEnv.

brad, according to https://developer.mozilla.org/En/GRE , section "Statically link to xpcomglue.lib (the "standalone glue") " XR stub can not link to NSPR as it is statically getting linked against the glue. that is why we are implementing our own setenv routine.

Revision history for this message
In , Tonikitoo (tonikitoo) wrote :

Created an attachment (id=370876)
patch 0.6 - add -app support to xulrunner-st

addressed mark's comment + fixed problem w/ the way it was looking for libxpcom in the same dir as the stub.

Revision history for this message
In , Tonikitoo (tonikitoo) wrote :

fixed error in patch 0.6:

* new patch:

+ if (!greFound) {
+ lastSlash = strrchr(iniPath, PATH_SEPARATOR_CHAR);
+ if (!lastSlash)
+ return 1;
+
+ *(++lastSlash) = '\0';
+
+ snprintf(greDir, sizeof(greDir), "%s" XPCOM_DLL, iniPath);
+ greFound = FolderExists(greDir);
+ }

* previous patch:

+ // We have a valid application.ini path passed in to the -app parameter
+ // but not yet a valid greDir, so lets look for it also on the same folder
+ // as the stub.
+ if (!greFound) {
+ snprintf(greDir, sizeof(greDir), "%s" XPCOM_DLL, iniPath);
+ greFound = FolderExists(greDir);
+ }

Revision history for this message
In , Tonikitoo (tonikitoo) wrote :

Created an attachment (id=370959)
patch 0.7 - add -app support to xulrunner-stub

more xp-like IsArg implementation. from irc:

<blassey> fine by me
<mfinkle> yes, looks good

Revision history for this message
In , Mark-finkle (mark-finkle) wrote :

(From update of attachment 370959)
Benjamin - The only odd thing you might notice in this patch (hopefully) is the second look for the greDir.

I had Antonio only do this check if the -app param was used so it didn't change the old behavior of the stub. We need to allow for the stub to be _in_ the greDir (instead of above it as the first check assumes) for WinCE at least.

Revision history for this message
In , Benjamin Smedberg (Mozilla) [:bs] (benjamin-smedbergs) wrote :

(From update of attachment 370959)
>diff --git a/xulrunner/stub/nsXULStub.cpp b/xulrunner/stub/nsXULStub.cpp

This file uses nsWindowsWMain.cpp. I think this means that all Windows char* in this file are UTF8, not native charset. If this is the case, several i18n bugs were already present in the Windows (desktop) version, but are being made more explicitly bad in the WINCE version.

If this is *not* the case, we should really make it clear which char* are the UTF8-munged kind and which are truly native, probably using typedefs.

>+static PRBool FolderExists(const char* aDir)
>+{
>+#ifdef WINCE
>+ wchar_t wideDir[MAX_PATH];
>+ MultiByteToWideChar(CP_ACP, 0, aDir, -1, wideDir, MAX_PATH);

CP_UTF8

>+ DWORD fileAttrs = GetFileAttributesW(wideDir);
>+ return fileAttrs != INVALID_FILE_ATTRIBUTES;
>+#else
>+ return access(aDir, R_OK) == 0;

Should be _waccess

>+static nsresult GetRealPath(const char* appDataFile, char* *aResult)
>+{
>+#ifdef XP_WIN
>+ wchar_t wAppDataFile[MAX_PATH];
>+ wchar_t wIniPath[MAX_PATH];
>+ MultiByteToWideChar(CP_ACP, 0, appDataFile, -1, wAppDataFile, MAX_PATH);

CP_UTF8

> class AutoAppData
> {
> public:
> AutoAppData(nsILocalFile* aINIFile) : mAppData(nsnull) {
> nsresult rv = XRE_CreateAppData(aINIFile, &mAppData);
> if (NS_FAILED(rv))
>@@ -186,17 +241,16 @@ main(int argc, char **argv)
>
> #ifdef XP_WIN
> wchar_t wide_path[MAX_PATH];
> if (!::GetModuleFileNameW(NULL, wide_path, MAX_PATH))
> return 1;
>
> WideCharToMultiByte(CP_ACP, 0, wide_path,-1,
> iniPath, MAX_PATH, NULL, NULL);

I think this should be CP_UTF8 also

>+ char *result = (char*) calloc(sizeof(char), MAXPATHLEN);
>+ memset(result, 0, MAXPATHLEN);

It shouldn't be necessary to calloc() and memset this data: calloc initializes to 0

Revision history for this message
In , Mark-finkle (mark-finkle) wrote :

(In reply to comment #38)
> (From update of attachment 370959 [details])
> >diff --git a/xulrunner/stub/nsXULStub.cpp b/xulrunner/stub/nsXULStub.cpp
> >+ DWORD fileAttrs = GetFileAttributesW(wideDir);
> >+ return fileAttrs != INVALID_FILE_ATTRIBUTES;
> >+#else
> >+ return access(aDir, R_OK) == 0;
>
> Should be _waccess

access -> _waccess or we should use _waccess in the WINCE block? I'm pretty sure _waccess is not supported on WinCE

Revision history for this message
In , Benjamin Smedberg (Mozilla) [:bs] (benjamin-smedbergs) wrote :

Windows desktop should not use access() on a UTF8 char*. It should either use the GetFileAttributesW code above, or should use _waccess.

Revision history for this message
In , Tonikitoo (tonikitoo) wrote :

Created an attachment (id=372700)
patch 0.8 - add -app support to xulrunner-stub

fixed benjamin's comments.

Revision history for this message
In , Tonikitoo (tonikitoo) wrote :

> >+static PRBool FolderExists(const char* aDir)
> >+{
> >+#ifdef WINCE
> >+ wchar_t wideDir[MAX_PATH];
> >+ MultiByteToWideChar(CP_ACP, 0, aDir, -1, wideDir, MAX_PATH);
>
> CP_UTF8

done.

> >+ DWORD fileAttrs = GetFileAttributesW(wideDir);
> >+ return fileAttrs != INVALID_FILE_ATTRIBUTES;
> >+#else
> >+ return access(aDir, R_OK) == 0;
>
> Should be _waccess

instead of #WINCE it was changed to #WINXP, so both will be using GetFileAttributesW as suggested.

> >+static nsresult GetRealPath(const char* appDataFile, char* *aResult)
> >+{
> >+#ifdef XP_WIN
> >+ wchar_t wAppDataFile[MAX_PATH];
> >+ wchar_t wIniPath[MAX_PATH];
> >+ MultiByteToWideChar(CP_ACP, 0, appDataFile, -1, wAppDataFile, MAX_PATH);
>
> CP_UTF8

done.

> > public:
> > AutoAppData(nsILocalFile* aINIFile) : mAppData(nsnull) {
> > nsresult rv = XRE_CreateAppData(aINIFile, &mAppData);
> > if (NS_FAILED(rv))
> >@@ -186,17 +241,16 @@ main(int argc, char **argv)
> >
> > #ifdef XP_WIN
> > wchar_t wide_path[MAX_PATH];
> > if (!::GetModuleFileNameW(NULL, wide_path, MAX_PATH))
> > return 1;
> >
> > WideCharToMultiByte(CP_ACP, 0, wide_path,-1,
> > iniPath, MAX_PATH, NULL, NULL);
>
> I think this should be CP_UTF8 also

done.

> >+ char *result = (char*) calloc(sizeof(char), MAXPATHLEN);
> >+ memset(result, 0, MAXPATHLEN);
>
> It shouldn't be necessary to calloc() and memset this data: calloc initializes
> to 0

done.

Revision history for this message
In , Ikezoe-clear-code (ikezoe-clear-code) wrote :

(From update of attachment 372700)
>+static PRBool FolderExists(const char* aDir)
>+{
>+#ifdef WINXP
>+ wchar_t wideDir[MAX_PATH];
>+ MultiByteToWideChar(CP_UTF8, 0, aDir, -1, wideDir, MAX_PATH);
>+ DWORD fileAttrs = GetFileAttributesW(wideDir);
>+ return fileAttrs != INVALID_FILE_ATTRIBUTES;
>+#else
>+ return access(aDir, R_OK) == 0;
>+#endif
>+}

WINCE insted of WINXP maybe.

Revision history for this message
In , Benjamin Smedberg (Mozilla) [:bs] (benjamin-smedbergs) wrote :

(From update of attachment 372700)
>diff --git a/xulrunner/stub/nsXULStub.cpp b/xulrunner/stub/nsXULStub.cpp

>+#ifdef WINXP

I think you meant XP_WIN here?

r=me with that fixed

Revision history for this message
In , Bugmail-lassey (bugmail-lassey) wrote :
Revision history for this message
In , Tonikitoo (tonikitoo) wrote :

marking "wanted 191 ?"

it'd be nice to have it on 1.9.1, once fennec wince AND prism 1.0 would be using it.

Revision history for this message
In , Mark-finkle (mark-finkle) wrote :

It's also a relatively safe XULRunner stub only change. It would be a benefit to Linux distros that use FF+XR builds.

Changed in firefox:
status: In Progress → Fix Released
Revision history for this message
In , Mark-finkle (mark-finkle) wrote :

Created an attachment (id=373396)
Mac bustage fix

Gavin discovered bustage on Mac. Here's the fix.

Revision history for this message
In , Matthew-gertner (matthew-gertner) wrote :

*** Bug 492206 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Mark-finkle (mark-finkle) wrote :

I'd like to get this patch on 1.9.1 so Firefox on Linux, which uses XULRunner as a runtime, can support the same -app functionality as Firefox on Mac and Windows. This patch is local to xulrunner-stub and does not affect Firefox directly, or at all on Windows and Mac.

On Linux, this patch only affects using Firefox as a runtime to launch xulapps. The only risk is that the patch is in the startup path of Firefox on Linux, but this patch has baked for a while on trunk with no ill affects.

Revision history for this message
In , Beltzner (beltzner) wrote :

Benjamin: thoughts on comment 50? I'm inclined to take it if you feel that it's safe.

Revision history for this message
In , Karlt (karlt) wrote :

(From update of attachment 373396)
This landed as
http://hg.mozilla.org/mozilla-central/rev/cffd84cbe5bb

Revision history for this message
In , Karlt (karlt) wrote :

It attachment 373396 needed on 1.9.1?
1.9.1 includes <CFBundle.h> instead of <CoreFoundation/CoreFoundation.h>.

Revision history for this message
In , Mark-finkle (mark-finkle) wrote :

(In reply to comment #53)
> It attachment 373396 [details] needed on 1.9.1?
> 1.9.1 includes <CFBundle.h> instead of <CoreFoundation/CoreFoundation.h>.

Karl - That is from bug 482277 which is removing carbon code. That bug/patch does not seem to be going to 191, only trunk. So <CFBundle.h> should stay in 191.

Revision history for this message
In , Bruno Girin (brunogirin) wrote :
Revision history for this message
In , Karlt (karlt) wrote :
Revision history for this message
In , Matthew-gertner (matthew-gertner) wrote :

*** Bug 501678 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Mark-finkle (mark-finkle) wrote :

*** Bug 504197 has been marked as a duplicate of this bug. ***

Revision history for this message
Micah Gersten (micahg) wrote :

This was fixed with the initial release of Firefox 3.5.

Changed in firefox-3.5 (Ubuntu):
importance: Undecided → Medium
status: New → Fix Released
Revision history for this message
Micah Gersten (micahg) wrote :

Firefox 3.0 is only receiving Security Updates and major bug fixes at this point.

Changed in firefox-3.0 (Ubuntu):
importance: Undecided → Medium
status: Triaged → Won't Fix
Revision history for this message
Nobuto Murata (nobuto) wrote :

On karmic's firefox 3.5.3+build1+nobinonly-0ubuntu3,
Prism add-on 1.0b2 ( https://addons.mozilla.org/en-US/firefox/addon/6665 ) does not work properly.
Clicking the shortcut launches a normal Firefox browser window with the default homepage
not a prism style window with the converted page.

Revision history for this message
Nobuto Murata (nobuto) wrote :

This bug was marked as fix-released 2 months ago.
But it seems to be happening again.
So I have reported as a new Bug #448127 .

Changed in firefox:
importance: Unknown → High
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.