Ah, https://developer.mozilla.org/en/getting_started_with_xulrunner says:
"Note: In XULRunner 2.0, the chrome.manifest is now used to register XPCOM components in addition to its previous uses. Part of this change means the /chrome/chrome.manifest is no longer considered the "root" manifest. XULRunner will not check that folder location for a root-level chrome.manifest. You need to move your existing chrome.manifest to the application root folder, remembering to update the relative paths within the file. You could also just create a new application root-level manifest that includes the /chrome/chrome.manifest, which is what this tutorial will do." That would probably explain why xulrunner 2 never opens the conkeror manifest. (I'll poke at that next time I'm actually on my natty machine...) On Mon, Jun 27, 2011 at 4:25 AM, Mark Eichin <[email protected]> wrote: > Ah, it is the same (unexamined, only-2-days old) bug - turning on > signon.debug in about:config gets > > Login Manager: observer notified for form submission. > Login Manager: Checking if logins to http://www.instapaper.com can be saved. > Login Manager: Searching for logins matching host: > http://www.instapaper.com, formSubmitURL: http://www.instapaper.com, > httpRealm: null > Pwmgr Prompter: ===== initialized ===== > Pwmgr Prompter: Notification bars not available on window > Login Manager: Caught error in onFormSubmit: [Exception... "Component > returned failure code: 0x80004005 (NS_ERROR_FAILURE) > [nsIStringBundle.formatStringFromName]" nsresult: "0x80004005 > (NS_ERROR_FAILURE)" location: "JS frame :: > file:///usr/lib/xulrunner-2.0/components/nsLoginManagerPrompter.js :: > <TOP_LEVEL> :: line 1343" data: no] > Login Manager: onStateChange accepted: req = > http://www.instapaper.com/user/login, flags = 0x30004 > Login Manager: domEventListener: got event DOMContentLoaded > Login Manager: onStateChange accepted: req = > http://www.instapaper.com/u, flags = 0x30004 > Login Manager: domEventListener: got event DOMContentLoaded > Login Manager: Counting logins matching host: > http://www.instapaper.com, formSubmitURL: , httpRealm: null > > nsLoginManagerPrompter.js line 1343 is in _getLocalizedString, which > is certainly called from all of the prompters... > > Ah. the rememberPassword tag is defined in xulrunner, in > chrome/en-US.jar (in passwordmgr.properties); strace confirms that > conkeror *never opens that file*. For that mater, it never opens > chrome.manifest which points to chrome/en-US.manifest... anyone know > how those bits are supposed to work? (I haven't tried going back to > the maverick box and tracing them there yet.) Oh, actually, I *can* > confirm that xulrunner-1.9.2 running the conkeror application.ini > works just fine, it only breaks with xulrunner-2.0 (or, as issue358 > suggests, xulrunner-2.0.1.) > > So, anyone have ideas on that? I assume we *don't* want to change the > nightlies to point to 1.9.2 instead, since 2.0 (and 5.0, presumably) > are the future, and at least the start up script is intentionally > looking for the newest one... > > > > > On Mon, Jun 27, 2011 at 3:56 AM, Mark Eichin <[email protected]> wrote: >> mmm, this might be an instance of http://bugs.conkeror.org/issue358 >> except that my already-saved conkeror.org username/password works just >> fine (it's clearly *reading* signons.sqlite, just not updating it...) >> >> On Mon, Jun 27, 2011 at 3:00 AM, Mark Eichin <[email protected]> wrote: >>> Anyone else seeing this? conkeror in maverick works fine, but in natty >>> (using the noone.org conkeror nightlies) signons.sqlite never gets >>> updated, when I log in to instapaper in particular. I only noticed >>> this because I was using an improved version of Loïc d'Anterroches' >>> instapaper mode which uses nsILoginManager.findLogins to get the saved >>> password instead of hard-coding it - which now fails, because it never >>> gets saved in the first place (I don't get prompted to save it, >>> either) so I don't know how long it's been broken (I only just started >>> using natty a couple of weeks ago, fresh install but with a copy of >>> the old ~/.conkeror.mozdev.org tree.) >>> >>> strace confirms that it's opening signons.sqlite. Moving it out of >>> the way does cause a new one to be created but that doesn't change the >>> behavior. (looking with sqlitebrowser, it's not in moz_disabled >>> either, so it's not blocked... though the username is coming from >>> formhistory.sqlite, after I type the first letter at least, I don't >>> think that gets in the way... any other ideas for debugging this? >>> >>> For that matter, is there a stable build that's appropriate for natty, >>> or are the nightlies the best choice right now? >>> >>> -- >>> _Mark_ <[email protected]> <[email protected]> >>> >> >> >> >> -- >> _Mark_ <[email protected]> <[email protected]> >> > > > > -- > _Mark_ <[email protected]> <[email protected]> > -- _Mark_ <[email protected]> <[email protected]> _______________________________________________ Conkeror mailing list [email protected] https://www.mozdev.org/mailman/listinfo/conkeror
