User:Sardisson/Troubleshoot Camino Bugs and Features Scratchpad

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