Closed Bug 306340 Opened 19 years ago Closed 15 years ago

DOM Inspector "CSS Style Rules" panel suddenly does not display any selectors

Categories

(Other Applications :: DOM Inspector, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: newslogic, Unassigned)

References

Details

(Keywords: regression)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6

[n.b. there was no "DOM Inspector" option under the component field in this
form, so it's filed under JS console.]

The DOM Inspector will not show any rules in the Object panel (top right) when
"CSS Style Rules" is selected. This behavior has begun suddenly. It worked fine
until just recently, and I've not modified my Firefox installation at all, as
far as I know. The only change that might have had an effect is the installation
of the new Google Desktop Search Beta (downloaded from Google 8/23/2005;
build=?); Google Desktop installed several files, including .dlls, in my Firefox
directories, but I've since uninstalled it and so don't know what those are
anymore. The uninstall of Google Desktop did not fix the problem; I can
reinstall if you need to know what these files are.

Reproducible: Always

Steps to Reproduce:
1. load url
2. open dom inspector (ctrl+shift+i)
3. select "css style rules" in the object panel

Actual Results:  
for any element, including elements known to have one or more applicable css
selectors (and which worked previously), nothing is shown in the window under
priority or property or value.

Expected Results:  
listed css selectors which apply to the selected element, and the file and line
number where the selector can be found
Assignee: nobody → dom-inspector
Component: JavaScript Console → DOM Inspector
Product: Firefox → Other Applications
QA Contact: javascript.console → timeless
I also have this problem. From what I could gather, it is caused by the service "@mozilla.org/inspector/dom-utils;1" failing to load. I think it might be an extension conflicting with the inspector earlier, so I tried disabling/re-enabling many of my extensions, and got the CSS Style Rules panel to work once, but once I restarted Firefox with those same settings, it went back to not working.
*** This bug has been confirmed by popular vote. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

I am experiencing this issue as well. No selectors show up: neither those in the page itself nor those that are Firefox-supplied (e.g., for H1).

I am almost certain this didn't correlate with installing any extension. It *seems* to have happened right around the FF .0.1 upgrade, but I can't say for sure.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

The keyconfig extension (version 20050908.2) seems to have caused this issue for me (though I'm not entirely sure about that). Disabling keyconfig made the DOM inspector work again, and re-enabling it didn't bring back the issue.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4

Me as well. It seems to be from being unable to QueryInterface the "@mozilla.org/inspector/dom-utils;1" service to inIDOMUtils.

Without a log, I can't identify if any extension may have caused this. The most recent action was upgrading to v1.5.0.4. Before that, I had installed the superT extension (although I thought that DOMi still worked after that...).
I can confirm that this bug is still present in Firefox 2.0. No amount of disabling/enabling extensions brought the functionality back.
Upgrading to Firefox 2 has reliably caused this bug across many Windows machines where I work.
Previously with 1.x.0.1 upgrades, I had to disable the DOM Inspector extension, restart Firefox, and re-enable the extension to fix the DOM Inspector being totally broken - this fix does not work any more.
Also a fresh profile exhibits this issue.
*** Bug 359446 has been marked as a duplicate of this bug. ***
*** Bug 359834 has been marked as a duplicate of this bug. ***
Keywords: regression
WinXP SP2 Home, FF2.0
also having this problem, did not have it on FF2.0RC3

Tried disabling all extensions except DOMi, and talkback, still no success.
Occasionally DOMi feels  bit sluggish compared to previous versions, like it's hanging internally somewhere.

JavaScript error console gives these warnings and info's on startup:

No chrome package registered for chrome://communicator/content/utilityOverlay.xul .

Warning: Failed to load overlay from chrome://communicator/content/utilityOverlay.xul.
Source File: chrome://inspector/content/inspector.xul
Line: 0

No chrome package registered for chrome://communicator/content/tasksOverlay.xul .

Warning: Failed to load overlay from chrome://communicator/content/tasksOverlay.xul.
Source File: chrome://inspector/content/inspector.xul
Line: 0

and then this error after selecting an element and switching to CSS Style rules view:
Error: this.mDOMUtils has no properties
Source File: chrome://inspector/content/viewers/styleRules/styleRules.js
Line: 322
The dump()ed error is:

Error getting service: @mozilla.org/inspector/dom-utils;1, inIDOMUtils [Exception... "ServiceManager::GetService returned failure code:"  nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)"  location: "JS frame :: chrome://inspector/content/jsutil/xpcom/XPCU.js :: anonymous :: line 43"  data: no]

And indeed, when I try Components.classes['@mozilla.org/inspector/dom-utils;1'].getService(Components.interfaces['inIDOMUtils']) in the JavaScript Console, I get this exception.

It does not work even in the safe mode, nor when I disable all extensions except the DOM Inspector (always the same message).

I also tried installing the same set of extensions on another computer where DOM Inspector works fine. All installed, it still works OK. No idea what could I try next...
(In reply to comment #11)
fyi, it's Components.classes["@mozilla.org/inspector/dom-utils;1"].getService(Components.interfaces.inIDOMUtils);

-----
Does everyone who is experiencing this reliably have inIDOMUtils in their xpti.dat file?  Mine looks like this:
227,inIDOMUtils,{78fd16c2-bdfb-4b1d-8738-d536d0a8f430},0,-1,1
(In reply to comment #12)
> > And indeed, when I try
> > Components.classes['@mozilla.org/inspector/dom-utils;1'].getService(Components.interfaces['inIDOMUtils'])
> > in the JavaScript Console, I get this exception.

> fyi, it's
> Components.classes["@mozilla.org/inspector/dom-utils;1"].getService(Components.interfaces.inIDOMUtils);

The two are equivalent.
(In reply to comment #13)
> The two are equivalent.

That's interesting.  When I tried the one he did I got the exception, however I didn't with the one I posted.
Are you sure you that wasn't due to a typo or copy/pasto? They both work fine for me.
(In reply to comment #12)
> Does everyone who is experiencing this reliably have inIDOMUtils in their
> xpti.dat file?  Mine looks like this:
> 227,inIDOMUtils,{78fd16c2-bdfb-4b1d-8738-d536d0a8f430},0,-1,1
> 

here's what i have:
224,inIDOMUtils,{ffffd059-13d1-4ef7-acb1-91188c6e31dd},2,-1,1
(In reply to comment #12)

I second comment #16 for two different WinXP Pro machines.  CSS Style Rules has been broken on both since the 1.5->2.0 upgrade.  Enabling/disabling extensions makes no difference.
(In reply to comment #15)
> Are you sure you that wasn't due to a typo or copy/pasto? They both work fine
> for me.
> 

same here. both ways resulted the same dump:

Error: uncaught exception: [Exception... "ServiceManager::GetService returned failure code:"  nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)"  location: "JS frame :: javascript: Components.classes["@mozilla.org/inspector/dom-utils;1"].getService(Components.interfaces.inIDOMUtils) :: <TOP_LEVEL> :: line 1"  data: no]

Yes, comment #12 hit it: I had the same GUID in xpti.dat as in comment #16, as soon as I manually changed it to the other GUID, the DOM Inspector seems to work fine!
(In reply to comment #19)
> Yes, comment #12 hit it: I had the same GUID in xpti.dat as in comment #16, as
> soon as I manually changed it to the other GUID, the DOM Inspector seems to
> work fine!
> 

i tried editing xpti.dat with notepad and it didn't work for me. 
could you please give more detail of what you did? thanks : ]
So it seems that you folks have a different guid for your component, correct?  I guess we need to figure out how that is possible...
(In reply to comment #21)
> So it seems that you folks have a different guid for your component, correct? 

Exactly. I tried deleting the file and restarting Firefox, the recreated file again contains the wrong GUID (ffffd059-...). The same happened now, as Firefox has been updated to 2.0.0.1: after restart, my tweaked xpti.dat has been overwritten and now contains the wrong ID again, so CSS Style Rules is empty.

(In reply to comment #20)
> i tried editing xpti.dat with notepad and it didn't work for me. 
> could you please give more detail of what you did? thanks : ]

Please note that the correct xpti.dat file is located in your user profile directory (i.e. on Windows, it is something like c:\Documents and Settings\username\Application Data\Mozilla\Firefox\Profiles\xxxxxxxx.default\xpti.dat), not in the application directory (c:\Program Files\Mozilla Firefox\components\xpti.dat): xpti.dat in the application directory is an unused leftover from an old version, IIANM.

So, what I did: I exited Firefox, edited the xpti.dat file and replaced the line
223,inIDOMUtils,{ffffd059-13d1-4ef7-acb1-91188c6e31dd},2,-1,1
with
223,inIDOMUtils,{78fd16c2-bdfb-4b1d-8738-d536d0a8f430},0,-1,1

Started Firefox again and, voil&#224;! (I did that again after the upgrade and it still works.)
(In reply to comment #22)

great, now it worked! you're right about finding the correct xpti.dat file. it has to be the one in the profile directory.

thanks a lot :D
... folks, you are great. 
I don't know how long I de-installed and re-installed addons and googled for a solution (I had this problem since FF2.0 and continuing with 2.0.0.1). 
The replacement in xpti.dat works fine.
Kisses ... :)
Hi all
I have the same problem with CSS Style Rules in the DOM inspector as well.
Fixing the xpti.dat file (inIDOMUtils,{ffffd059..... -> inIDOMUtils,{78fd16c2...)
is fixing the problem, but the next time I change my Add-ons (installing, uninstalling, enable, disable) is bringing the wrong value in the xpti.dat again :(
I hope this is helping for the bug fixing...
Although this is a regression, it doesn't block Mozilla development, nor Inspector development.  Lowering severity.
Severity: blocker → normal
One small deviation from the previous comments:

I had this problem too, and when I edited my xpti.dat file, my "inIDOMUtils" line was:
222,inIDOMUtils,{ffffd059-13d1-4ef7-acb1-91188c6e31dd},1,-1,1

I changed the GUID to 78fd16c2-bdfb-4b1d-8738-d536d0a8f430, making the line:
222,inIDOMUtils,{78fd16c2-bdfb-4b1d-8738-d536d0a8f430},1,-1,1

After this change, every time I viewed CSS style rules on a page firefox.exe crashed with a GPF (error code 0xc00000005). Then I changed the third number from the left from 1 to 0:
222,inIDOMUtils,{78fd16c2-bdfb-4b1d-8738-d536d0a8f430},0,-1,1

This final change cleared up the GPF and now DOMi works fine.

sounds like a stale xpt file. can you guys list all the xpts you have (dir /s *.xpt) timestamps for them is of course important, and it'd be best if you attached the output to this bug (probably one attachment is sufficient).
URL: any
here's a different workaround i tested successfully that might bring some insight to the discussion.

it sums up to the following steps:


1. uninstall ff 2.0.0.1 from the control panel

2. remove the original application folder inside the default applications folder (it's not the profile folder)

3. reinstall ff 2.0.0.1 choosing dom inspector in the custom options


that's it. dom inspector styles worked correctly again. 

some remarks i found relevant:


- i didn't lose any configurations, bookmarks or add-ons. it was all there as before uninstall/remove app folder.

- dom inspector kept on working correctly even when i installed/updated extensions after the reinstallation. this was an issue with the xpti.dat fix: it had to be hand edited everytime an extension was installed/updated.

- there were three "inspector*" files in the 'mozilla firefox/components' folder that are there no more and it was suggested that they might be causing some kind of conflict:

  > inspector.dll (1.7.20050.25981)
  > inspector.xpt
  > inspector-cmdline.js


this was found combining different solutions that were mentioned on this thread in the firebug discussion group (membership needed):

http://groups.google.com/group/firebug/browse_thread/thread/b6a530059a7d1e/

hope this helps :)

cheers
(In reply to comment #30)
Confirmed that a clean install of FF2.current resolves this issue. Looks like this could be resolved for other users by the FF update tool cleaning up some of these bogus files?
Assignee: dom-inspector → nobody
QA Contact: timeless → dom-inspector
Shawn, was this an artifact of making Inspector into an extension?  Is there something we should still do here at this point?
(In reply to comment #32)
> Shawn, was this an artifact of making Inspector into an extension?  Is there
> something we should still do here at this point?
It was just caused by old/stale/bad xpt files.  I think this is WORKSFORME at this point.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.