StyledEdit crashes if started by be_roster->Launch

[donn]

See attached example. When started with be_roster->Launch("text/plain", refmsg), StyledEdit crashes in BPrivate::HaikuControlLook::_DrawButtonFrame(), an error which prevents it from continuing.

[diver]

Can't reproduce with x86_64. Are you sure you don't have an older StyledEdit binary lying somewhere?

[donn]

Excellent, that indeed appears to have been what happened - there were a couple, in the generated/ directories of an old build of the Haiku OS.

I'm sure BRoster::Launch() is the only way anything ever tried to run those copies of StyledEdit. It's quite bizarre that it would look there, for an application to deal with "text/plain". I think it didn't used to, but in any case I guess this behavior could appear somewhat random.

I guess this may be more or less the same bug as #6475 - if queries are going to be employed in ways that matter, like finding an application to execute for a particular task, then they need some way to prioritize the applications that were installed with the user's expectation that they'd be used for that kind of task. Like POSIX execvpe() uses PATH, instead of picking a randomly discovered instance of the specified file name. Along with the general expectation that things work as expected, there can be security problems, when the system unexpected gropes around in your files for an executable file.

[korli]

Since the introduction of PM residual executables on other partitions are not found anymore since the HPKGs (haiku.hpkg) are not mounted. This is really more a power user issue. No change required?

[donn]

Note that this StyledEdit wasn't a residual installed earlier on another partition. It was never installed, just built and laying around in my files, in the /boot partition. Consider the security implications!

If the assumption is that executables will be installed only in PM space, maybe file-type -> application launches should be limited to PM space. That's less flexible than PATH and could lead to some frustration, but I maybe everyone could live with it, and has a sane rationale.

[nielx]

Remove milestone for tickets with status = closed and resolution != fixed