52869 - InstallTrigger callbacks on the wrong thread

Status: RESOLVED WORKSFORME

(Core Graveyard :: Installer: XPInstall Engine, defect, P2)

Description

[Daniel Veditz [:dveditz]]

XPInstall callbacks are coming in on the XPInstall thread, and web pages which 
do UI stuff within them cause all sorts of problems. Doing a setTimeout() 
in the callback and doing the UI actions there seems to help, probably because 
the event queue is served on the correct UI thread.

This is causing problems for Netcenter's SmartUpdate site.

Comment 1

[Daniel Veditz [:dveditz]]

This is a relatively obscure problem and has a workaround (however ugly), I'm 
afraid it's got to be nsbeta3- for this release.  Of course that complicates 
life because either the SmartUpdate site has to be coded for two versions of N6 
or else it'll always have to use the ugly workaround just in case.

Comment 2

[Jimmy Lee]

Ccing David.

Comment 3

[Daniel Veditz [:dveditz]]

Risky change (involving threading) for first release, there is a workaround
we'll have to document.

Comment 4

[Daniel Veditz [:dveditz]]

Gee, it sure looks like I tried to get on the correct thread. Bummer if this is
still broken. nsbeta1

Comment 5

[Daniel Veditz [:dveditz]]

Moz 0.9 tasks

Comment 6

[Syd Logan]

reassigning

Comment 7

[Syd Logan]

Can I get some steps to duplicate this bug with? Might also be nice to check and 
see if it is still a problem, last touched in January.

Comment 8

[Blake Ross]

Missed 0.9.3.

Comment 9

[Syd Logan]

moving to mozilla1.0

Comment 10

[Daniel Veditz [:dveditz]]

Taking these two

Comment 11

[Jaime Rodriguez, Jr.]

Adding bug 108098 and bug 109139 as dependencies, because fixing this seems like
it will fix'em.

ADT2 per ADT/XPInstall triage.

Comment 12

[Daniel Veditz [:dveditz]]

bug 53622 is a better duplicate

*** This bug has been marked as a duplicate of 53622 ***

Comment 13

[Daniel Veditz [:dveditz]]

oops, wrong bug

Comment 14

[Daniel Veditz [:dveditz]]

There's code to switch this over to the correct thread, as far as I can tell
that's what's happening, but all that was written before this bug was. Without
the testcase showing where setTimeout() was required I can't really demonstrate
that a problem still exists.