12 thoughts on “Mouseover DOM Inspector

  1. holy crap. What’s it gunna take to get that in the tree? That’s so infinately useful it should be part of the Developers Tools option in the installer.

  2. In other circles it becomes Maturity Onset Diabetes of the Young (MODY) which is what it rings to me…

    Oh well that’s why medic geeks have such a laugh!

  3. This totally rocks!

    I’m wondering though if its safe to handle external JS files in bookmarkets in this manner. What if someone adds a bookmarklet that’s safe, but then the author is hacked and the JS file referenced is replaced with something malicious? Perhaps there could be a warning on first load, saying “You’re loading an external JS file from …”, and then another warning *if* the content of the JS file is ever changed.

    Complicated to implement, but it was just a passing thought of mine.

  4. Wow, that is cool! And supremely useful for Camino, too.

    To follow up in Ali Ebrahim’s point, can the JS be saved to disk and the bookmarklet edited to refer to a local file (I know next to nothing about JS)?

  5. Smokey: no, web pages cannot link to local files. You can save it on your own site or on a web server running on localhost.

  6. Here’s a Local source version…. but it doesn’t really help because inside the javascript file, it also fetches css and image files as well (maybe more.. I only took a quick look.)

    Also, it’s non polluting variable-wise, except for the prefFile that the script is expecting, but it does take up the ‘modi’ id as well, so a page with that could also mess up.

  7. Okay. Here’s a completely local version (as far as I can tell as well as ethereal :p)

    1) Bookmarklet loads a data uri javascript file
    2) Javascript file modified to load data uri status images and css file
    3) CSS file modified to have data uri url image references

    The only reference to http://slayeroffice.com/tools/modi/v2.0/ should be the help link and that isn’t automatically loaded.. so there shouldn’t be any automatic requests for js, css, png, gif files anymore.

    Modified/data uri’d: modi_v2.0.js, modi_v2.0.css, arrow_up.gif, arrow_down.gif, gray.png, outline.png

    I’ll send an email to the author about making a special link like I have with the data uri’s for Firefox users because only Firefox (other Gecko browsers?) can support such a long uri.

  8. Yes, such “JS substitution” attacks as Ali notes are possible, although his solutions are fairly impractical. It’s easier to have a local copy (with the author’s permission; I didn’t see any licensing info) on your own webserver (which gets around the http/file cross-access issues).

  9. Like I said, my solutions were a passing thought, and more of an “ideal solution”. I never said they were practical ;) Nevertheless, I still think that there’s some level of risk involved for the user here from a substitution attack. I’m not quite sure what the best (read: practical) way to tackle this would be, though.

    Perhaps the author could be persuaded to release this as a Firefox extension, and then updates could be handled via UMO. That would certainly solve the JS substitution issue, at the cost of a bit of flexibility.

  10. […] release this as a Firefox extension […]. That would certainly solve the JS substitution issue, at the cost of a bit of flexibility.

    And support for Camino :-( (Camino supports some .xpi extensions, but only if they’re UI-less or if someone writes a prefPane for them, e.g. CamiFlash for FlashBlock.)

    I was so excited about this because 1) it works in Camino, which doesn’t include the DOM Inspector, and it works via moseover and “just works” (whereas I’m often fighting DOM Inspector to get it to highlight an element or vice versa)….

    Many thanks Jan! and Edward for the server/localhost tip and the rewritten-to-be-local version (and to Gerv for the orginal find)!