Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#2772 closed bug (fixed)

Firefox doesn't start

Reported by: nopper Owned by: bonefish
Priority: normal Milestone: R1
Component: - General Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: x86

Description

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.

Change History (12)

comment:1 Changed 11 years ago by 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?

comment:2 in reply to:  1 ; Changed 11 years ago by nopper

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

comment:3 Changed 11 years ago by axeld

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

comment:4 in reply to:  2 ; Changed 11 years ago by 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.

comment:5 in reply to:  4 Changed 11 years ago by 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

comment:6 Changed 11 years ago by bonefish

Owner: changed from axeld to bonefish
Status: newassigned

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.

comment:7 Changed 11 years ago by bonefish

Resolution: fixed
Status: assignedclosed

Fixed in hrev27732.

comment:8 Changed 11 years ago by 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?

comment:9 in reply to:  8 Changed 11 years ago by 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.

comment:10 Changed 11 years ago by 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).

comment:11 in reply to:  8 Changed 11 years ago by 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 ?

comment:12 Changed 11 years ago by tqh

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

Note: See TracTickets for help on using tickets.