Firefox doesn't start

[nopper]

I get this error on real hardware and also using qemu and a raw image generated with latest revision:

Signature in rsrc doesn't match construtctor arg. (application/x-vnd.Haiku-RuntimeLoader, application/x-vnd.Mozilla-Firefox)

I've tried to modify the signature to application/x-vnd.Haiku-RuntimeLoader without success.

[bonefish]

I assume you built your images yourself. Attribute mixups are known to happen when building without xattr support (i.e. configuring without --use-xattr) and when not building from the scratch (i.e. after deleting generated/objects and generated/attributes).

Is this the case?

[nopper]

Yes but I've also tried with ​http://haiku-files.org/raw/haiku.image.r27723.bz2 without any results.

[axeld]

I would guess this is the "first image is my app image" issue as introduced recently with the profiling code.

[bonefish]

Replying to nopper:

Yes but I've also tried with ​http://haiku-files.org/raw/haiku.image.r27723.bz2 without any results.

The images don't even contain Firefox. How did you install it?

Replying to axeld:

I would guess this is the "first image is my app image" issue as introduced recently with the profiling code.

Interesting idea, but BApplication::_InitData() uses get_app_ref(), which searches for the B_APP_IMAGE. Besides, if that were the problem, the warning would be printed for all applications, which it isn't. I haven't tried Firefox yet -- my source tree isn't in a buildable state ATM. Will check in a few minutes.

[nopper]

Replying to bonefish:

The images don't even contain Firefox. How did you install it?

wget ​http://www.yellowbites.com/downloads/Firefox-2.0.0.12.zip

[bonefish]

OK, I can reproduce the problem. According to strace Firefox tries to get the signature it passes to the BApplication constructor for its executable (for whatever reason), but uses the first image info to find the file.

[bonefish]

Fixed in hrev27732.

[tqh]

I suspect we have image loading in three places where this is one of them, so being compatible with BeOS in this regard is good. Also since we are so far behind the development branch it might be hard to get them into Mozilla anyway.

This issue is from the fact that the Mozilla base code is used for all apps (Firefox, Thunderbird, Songbird and so on) and we can't really decide the mime-type at compile time. We could/should probably change this hack for a better one, but it will still be a hack. Maybe there is something clever to do on the BApp side?

[bonefish]

Replying to tqh:

I suspect we have image loading in three places where this is one of them, so being compatible with BeOS in this regard is good. Also since we are so far behind the development branch it might be hard to get them into Mozilla anyway.

This issue is from the fact that the Mozilla base code is used for all apps (Firefox, Thunderbird, Songbird and so on) and we can't really decide the mime-type at compile time. We could/should probably change this hack for a better one, but it will still be a hack. Maybe there is something clever to do on the BApp side?

If you have no other way of finding out which application it is, then I guess getting the signature from the file is the only option. We could allow passing a NULL signature to the BApplication constructor in such a case.

[tqh]

The option is to add #ifdefs for known Mozilla apps and fail for others with #error unknown app or such. It will simplify the code at the cost of many lesser known Mozilla apps will fail to build (or work).

[jackburton]

Replying to tqh:

I suspect we have image loading in three places where this is one of them, so being compatible with BeOS in this regard is good.

Yeah but you could change that code to be compatible with haiku AND beos, since assuming that the first image is the app image is.. well, an assumption :) Better change the code to be more correct, no ?

[tqh]

Yes of course. It's all a question of motivation, which is all gone when it comes to Firefox...