User:Sardisson/Troubleshoot Camino Bugs and Features Scratchpad

From Camino Wiki
Jump to navigation Jump to search

What does Troubleshoot Camino “change”?

Troubleshoot Camino does three basic things as part of “using a fresh profile”:

  • creates a temporary clean profile folder, with default Camino preference settings
  • creates a temporary clean cache folder (including site icon cache)
  • informs any hacks (InputManagers, Unsanity haxies, APE modules) that respect the CAMINO_DISABLE_HACKS environment variable[1] not to load, thereby disabling them in Camino for the session

What does Troubleshoot Camino not change?

Troubleshoot Camino does not:

  • use or create a clean org.mozilla.camino.plist Cocoa property list file
  • move, touch, or otherwise modify the default Camino profile folder or cache folder

Bugs

1.1

  • v.1.1 needs to export CAMINO_DISABLE_HAXIES so InputManager haxies can look for it and not load.

1.2.1.1

  • Sometimes continues trying to launch Camino after encountering an error which should terminate the launching process. fixed in Mar 2007 1.2.2 beta and 1.2.1.1
  • Troubleshoot Camino can be not-the-active-app when it tries to show some dialogues (e.g., a version of Camino too old to be compatible). fixed this in the JEP app with sprinklings of "activate"; fixed in 1.2.1.1
  • 1.2.1 fails on 10.6 with "Can't make “CHIM” into boolean" message fixed in 1.2.1.1 by backporting rewritten cmCreator comparison from 1.2.2 betas

1.2.2

  • Troubleshoot Camino can be not-the-active-app when it tries to show some dialogues (e.g., a version of Camino too old to be compatible).
    fixed this in the JEP app with sprinklings of "activate" and fixed in 1.2.1.1; needs forward-porting

Feature Requests

1.2.2

  • possibility to start with about:blank
    Probably the way to implement this is to read a preferred homepage from a user defaults key, then echo it into the profiledir's user.js before launching Camino; this should approximate what Tinderboxen and test harnesses do to launch apps
    • If the last-ordered pref's value is not in quotes, the parsing code barfs right now
    • Sometimes we fail with "profile folder already exists", which seems to be really bad luck with random not being random :/ Did this change appreciably in the dev version?
      • I'm seeing this again on 10.3.9; the last time I looked, the diff was insignificant
      • Maybe in a failure case, that value is getting saved internally?
        • rnd itself gets cleared before being populated on each run, and the profile path is constructed by calling rnd, not by calling some other var that might be saved
      • This (seems) to go away when I re-save on 10.3.9
      • One other way of possibly working around this/future-proofing is to re-call the rnd function when mkdir -p fails
    • If there is only one pref, the dict is a single line on 10.3.9; it's always at least 3 lines on 10.5 fixed in b8
    • On 10.3.9, the prefs are being written with leading spaces somehow; this doesn't happen on 10.5 fixed in b8
    • If there are no user prefs defined (and the global value is properly cleared, which might be happening in b9/b10, then the app quickly notices userPrefsList is undefined and fails before code prior to needing userPrefsList even runs!
  • remember location of last-launched Camino
    • Various keys control this, and the interplay between them is not clear; plus, the keys differ between OS versions.
  • Make it clear in the "This copy of Camino is already running" warning that "Quit" is "Quit TC" and not "Quit the already-running Camino"
    • N.B. It's not safe to quit the already running Camino, because that may be your normal Camino (and you don't want dataloss) and because with running Caminos > 1, the one that gets quit is indeterminate
  • Needs a snazzy icon (ss)
    • I just got this image of an el Camino with the hood up and a little Camino icon holding a wrench (sardisson)
    • Needs to be different enough (at 20-24px) from Camino that I can tell it apart from the 2-3 Caminos also in my Dock at any given time

TC.next

(Requires Mac OS X 10.4)

  • Move to "localized string" instead of custom locale and string code
  • Move to "property list item" instead of custom user defaults reading/writing code
  • Move to bundle identifier?

Future

  • handling org.mozilla.camino.plist to ensure freshness
  • option to re-use last fresh profile for testing round-trip bugs
  • option to specify a (permanent) custom profile? (i.e., as an alternative to hacking the app plist)
  • Troubleshoot Firefox
    • This would of course be a separate util; most of the needed code exists in the NSPR logging utils and in TC