Closed Bug 594299 Opened 14 years ago Closed 10 years ago

(d3d9-layers)inFlasher doesn't flash

Categories

(Other Applications :: DOM Inspector, defect)

x86
Windows 7
defect
Not set
normal

Tracking

(blocking2.0 -)

RESOLVED INVALID
mozilla2.0
Tracking Status
blocking2.0 --- -

People

(Reporter: alice0775, Unassigned)

References

Details

(Keywords: regression)

Build Identifier: Mozilla/5.0 (Windows torNT 6.1; WOW64; rv:2.0b6pre)
Gecko/20100907 Firefox/4.0b6pre ID:20100907041859

inIFlasher doesn't flash.
If I set layers.accelerate-all to false, it works.


Reproducible: Always

Steps to Reproduce:
1. Start Minefield with new profile
2. Install DOM inspector ( https://addons.mozilla.org/ja/firefox/addon/6622/ )
3. Inspect any element

Actual Results:
 inIFlasher doesn't flash

Graphics

Adapter Description: ATI Radeon HD 4300/4500 Series
Vendor ID: 1002
Device ID: 954f
Adapter RAM: 512
Adapter Drivers: aticfx64 aticfx64 aticfx32 aticfx32 atiumd64 atidxx64 atiumdag
atidxx32 atiumdva atiumd6a atitmm64
Driver Version: 8.762.0.0
Driver Date: 8-3-2010
Direct2D Enabled: true
DirectWrite Enabled: true
GPU Accelerated Layers Enabled: 1/1  Direct3D 9
According to https://wiki.mozilla.org/Platform/2010-09-07#Firefox_Development,
Implement of Inspector was dropped from Firefox 4.

So, I think this should be fixed before release of Firefox4.
blocking2.0: --- → ?
Eh?  Two things:
a) The devtools inspector (https://wiki.mozilla.org/Firefox/Projects/Inspector) uses a different method for its highlighter; it's not inFlasher.
b) Even if it were the case that the devtools inspector did use inFlasher, the fact that it was dropped from Firefox 4 would imply that this shouldn't be blocking, *not* that it should be...
Status: NEW → RESOLVED
blocking2.0: ? → ---
Closed: 14 years ago
Resolution: --- → DUPLICATE
Summary: (d3d9-layers)inIFlasher doesn't flash → (d3d9-layers)inFlasher doesn't flash
(In reply to comment #2)
> Eh?  Two things:
> a) The devtools inspector (https://wiki.mozilla.org/Firefox/Projects/Inspector)
> uses a different method for its highlighter; it's not inFlasher.
> b) Even if it were the case that the devtools inspector did use inFlasher, the
> fact that it was dropped from Firefox 4 would imply that this shouldn't be
> blocking, *not* that it should be...
Note that this is new breakage on a platform that inIFlasher actually worked on - windows.  This isn't really the same as bug 368608.
(In reply to comment #3)
> Note that this is new breakage on a platform that inIFlasher actually worked on
> - windows.  This isn't really the same as bug 368608.

The effect is the same though, right?  "Rewrite DOM Inspector's flasher"?  The platform fields for that bug are already All/All.
(In reply to comment #4)
> The effect is the same though, right?  "Rewrite DOM Inspector's flasher"?  The
> platform fields for that bug are already All/All.
It's not clear to me that that is the case.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
This is about Extention DOMi's  blinking feature.

I think this is not bug 368608 completely.
Because, Blinking of DOMi works before enabling D3D9.
And It still works if I disabled D3D9.
This is regression, 
is this block 2.0?
blocking2.0: --- → ?
Keywords: regression
Target Milestone: --- → mozilla2.0
blocking2.0: ? → -
Has this been fixed in nightly builds or preview releases?

I can confirm that unchecking "User hardware acceleration when available" is a workaround if blinking is not working. My video card is NVIDIA GeForce 9500 GS. I am developing a web application that heavily utilizes Canvas and SVG so I would much prefer not to have to disable hardware acceleration. Is there are less drastic workaround?
Flasher in DOMi was rewrited in Nightly 33.0a1

So, this bug is obsoleted.
Status: REOPENED → RESOLVED
Closed: 14 years ago10 years ago
Resolution: --- → INVALID
s/rewrited/rewritten/
You need to log in before you can comment on or make changes to this bug.