Closed Bug 435517 Opened 16 years ago Closed 1 month ago

Feed helper apps can wedge open with dialogs

Categories

(Camino Graveyard :: General, defect)

All
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: stuart.morgan+bugzilla, Unassigned)

Details

(Whiteboard: rdar://5962612)

Attachments

(1 file)

I've occasionally seen weirdness in my debug builds where a window opens for each of the feed handlers on launch asking whether or not it should run, with "Run" and "Quit" buttons (I forget the exact text). The windows can't be focused so the buttons can't be clicked (maybe because of being ui-less apps), and they have no Dock tiles, so there's no way to quit them without resorting to Terminal or Activity Monitor.

Since it had only in my debug builds I didn't worry about it, but I just got a report of this happening to someone on updating to 1.6.1. We need to figure out how it's possible for these scripts to show a dialog.
I saw this the other day in my debug build, too, and wasn't sure what was happening.

I assume they're not focusable because of LSBackgroundOnly, and they're coming up from the "first launch-ing" stuff.  Unfortunately, those two are part of the fix for bug 415319 comment 5 and 6.  I have no idea what's really causing them to appear in these rare instances, though.

Peter, do you have any idea why we might be seeing them?
Hardware: PC → All
Stuart, did they look like this?  I didn't get a good look because mine were stuck behind some other windows, but I thought they were smaller (not as tall, no icon).

(This is what you see when you launch an AS app for which you've enabled a startup screen—which we haven't, of course.)

Whoever sees this again first needs to get a screenshot for Peter.
Once Peter popped out the startup screen idea and I saw the startup screen looked "close", I went to consult Uncle Google.

Uncle Google tells me that if an applet is launched while ctrl is held down, it will show a startup screen even though it has been compiled not to.  If that's not what happening here, it's something that looks very similar.  Given that we delay launching, it can be a bit of random bad luck that ctrl is down when they're launched.

I have half a mind to rdar:// part of this, since applets set to LSBackgroundOnly really shouldn't be allowed to throw unexpected, randomly-triggered dialogues the user can't cancel (or see; on 10.3.9, you don't even get to see them).

In terms of fixing this bug, we could go back to LSUIElement, which should make  the dialogues focusable and cancelable when someone does manage to trigger them, but it would also mean that everybody would see three flashes (and three focus-stealing events) every time they launch a new Camino.
That definitely seems worth filing with Apple.

That does seem like the right dialog, although they would have had the appropriate icons. Perhaps, given the ctrl problem, we should re-write them as compiled binaries (still controlled by a text file with the URL so they are easy to add or update)?
The fact that LSBackgroundOnly applets show stuck startup screens is filed as rdar://5962612.
Whiteboard: rdar://5962612
Status: NEW → RESOLVED
Closed: 1 month ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: