Closed Bug 385909 Opened 17 years ago Closed 15 years ago

rewrite inIFlasher interface

Categories

(Other Applications :: DOM Inspector, enhancement)

x86
Windows XP
enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 368608

People

(Reporter: timeless, Unassigned)

References

Details

For reference, I'm currently playing with inIFlasher in an embedding context, we really don't have any xul, but we'd like to be able to flash or retain a number of objects at a single time (and ideally have a relatively easy way to discard them ...). inIFlasher is currently a service, which is problematic because its attributes are therefore shared among n consumers (this results in DOMI looking confused often). I'd prefer something like this: inIFlashObject createFlash(in DOMNode node, in long aDuration, in long aSpeed, in boolean aHold, in DOMString aColor, in long aThickness, in boolean aInvert) which does something like: 1. create an inIFlashObject that remembers all these details 2. adds the object to a list of things to flash 3. deals w/ scheduling flashing 4. returns the object the returned inIFlashObject would contain each of those bits as a property (and each bit would be writable, so you could e.g. change the node or duration). there would also be a method to delete a flashing object possibly inIFlashObject.stop() [or inIFlasher.remove(inIFlashObject)] would remove it from the list in 2 so that the service no longer holds a reference and inIFlashObject can go away in peace at any time. I don't think it's easy for inIFlasher (service) to use WeakReferences to in inIFlashObject's instead of normal references, because while it'd mean that a consumer could let go of all of its objects at once and the next time the flashing code went to work, it would recognize that they're gone, it wouldn't know how to unpaint them. And you can't unpaint an object during a GC(). Yes, this bug is kinda more like an unfinished note than something else, but it's i think close enough and I need to dump my thoughts somewhere.
inIFlasher doesn't even work on the mac right now without the risk of crashing, sadly. It really does need to be revamped
Well, any progress for this issue? That's the problem that I have now -- inIFlasher stopped working on Mac for ff3. ff2 works fine. Shawn, what do you mean by saying 'without the risk of crashing'? Do you have any use case that I can reproduce the crashing?
It just randomly seems to crash - don't know of a reproducible test case.
I have a quick fix for this issue. (Actually a work around in case someone need it.) It's in JS. I tried to set the 'outline' attribute for that xul element. Something like: - in paintOn() method: this.flashElement.setAttribute('style', 'outline-width: 2px; outline-offset: 2px; outline-style: solid; outline-color: '+this.mShell.color+';'); - in paintOff() method: this.flashElement.setAttribute('style', 'outline-width: 0px;'); Of cause you need find a way to pass a flashElement to the method.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.