User:Sardisson/Troubleshoot Camino Bugs and Features Scratchpad
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_HACKSenvironment variable 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.plistCocoa property list file
- move, touch, or otherwise modify the default Camino profile folder or cache folder
v.1.1 needs to export CAMINO_DISABLE_HAXIES so InputManager haxies can look for it and not load.
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 18.104.22.168 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 22.214.171.124 1.2.1 fails on 10.6 with "Can't make “CHIM” into boolean" messagefixed in 126.96.36.199 by backporting rewritten cmCreator comparison from 1.2.2 betas
- 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 188.8.131.52; needs forward-porting
- 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
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.5fixed in b8 On 10.3.9, the prefs are being written with leading spaces somehow; this doesn't happen on 10.5fixed 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
(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?
- 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