Closed
Bug 385909
Opened 17 years ago
Closed 15 years ago
rewrite inIFlasher interface
Categories
(Other Applications :: DOM Inspector, enhancement)
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.
Comment 1•17 years ago
|
||
inIFlasher doesn't even work on the mac right now without the risk of crashing, sadly. It really does need to be revamped
Comment 2•17 years ago
|
||
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?
Comment 3•17 years ago
|
||
It just randomly seems to crash - don't know of a reproducible test case.
Comment 4•17 years ago
|
||
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.
Comment 6•15 years ago
|
||
Dupe of bug 368608?
Updated•15 years ago
|
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.
Description
•