Well, it seems I cannot reproduce it on linux, only on Win XP. On that machine I cannot do regression testing.
And there seems to be a bug in the extension. Even when I comment out the script in chrome/userchrome.js , it still does execute. Or when I update it, it does not pick up the new code. I found out an old cached copy of it is executing from startupcache/startupcache.4.little . When I delete the file, the script does update.
why would i need it ? moreover, firefox seems to have recreated it anyways. i have the conviction that the script for userchromejs 1.4 is working actually, "but", i have an issue .. . it's only working for new windows i close & reopen, firefox's size & position aren't reminded but the default script's info is, so it seems to work, But .. .
All sessions i reload, & that is another issue, cause i always reload sessions through session manager, bypass the script, it seems that session manager saves windows positions & restores them .. .
Hi aceman, the author of session manager emailed me that answer:
Firefox itself is actually setting the window size and position bases on the values stored in the session data. Session Manager gets that data from Firefox. The only way to do what you want is if Session Manager removed the window position and size info from the session data. I don't think that would help in your case since your script would still run before Firefox finishes loading the window.
You should have your code run after the window loads by running it in an event listener as follows:
if (location == "chrome://browser/content/browser.xul") { alert("init"); setTimeout(set_my_size,3000); }
(window.addEventListener didn't work work me either.)
All the alerts get executed, so I don't know why the window size is not changed. That is a question for the author. Remember to always delete the startupcache.4.little file after making any changes to the script. Also ask the author why that is necessary, if he can't invalidate the cache automatically from inside the extension.
userChromeJS executes the code it is given and as long as it does so there is no bug; it is certainly beyond its purview to know what issues may arise with the code it is given.
prior posts here mention how caching can be bypassed, either by code given to userChromeJS or by a command line switch on Fx/Tb startup. there will be no method included in the extension to clear caches.
userChromeJS runs in privileged mode and has all access, thus it is a developer tool for people who know what the code is doing. people should understand that blindly running code, which could be malicious, is unadvised. userChromeJS is not Stylish, despite its use there to do things css cannot do.
as for setting those attributes, with Session Manager and perhaps even core Fx, it should be completely unnecessary as far as remembering window position/dimensions. further, such things are OS specific, negative values may be illegal.
i use your extension in the case some devs could offer me a quicker fix than having to write an extension, & i'd really appreciate if you could please fix my code in order to keep all windows i open in the same size & position in firefox.
Also, if you know how to create codes for those unanswered requests, please help:
/* Open tab right to the current one */ eval("gBrowser.addTab ="+gBrowser.addTab.toString().replace( 'if (!blank)', 'this.moveTabTo(t,this.mCurrentTab._tPos+1);'+ 'if (!blank)'));
/* For each tab opened in background, put the flag "unread" (until they are selected), in order to use css properties to change font color, etc. */ gBrowser.addEventListener("TabOpen", function(aEvent) { aEvent.originalTarget.setAttribute("unread", ""); }, false); gBrowser.addEventListener("TabSelect", function(aEvent) { aEvent.originalTarget.removeAttribute("unread"); }, false);
It works buggy: After every restart it changes the taborder. After two restarts the order is like before (?).
There is a bug in userChromeJS 1.4 which prevents it from creating userChrome.js properly on recent Thunderbird and Firefox versions. The problem is that Thunderbird and Firefox no longer unpack XPI files by default -- they both leave them packed in the extensions directory and extract files from them as needed. userChromeJS expects the README.txt file to be available to copy into userChrome.js, but it's not there because it's in the XPI. I'm not sure what the proper fix is, but something needs to be done. People installing userChromeJS for the first time are having trouble finding userChrome.js to edit it (since it's not there!).
jikamens wrote:There is a bug in userChromeJS 1.4 which prevents it from creating userChrome.js properly on recent Thunderbird and Firefox versions. The problem is that Thunderbird and Firefox no longer unpack XPI files by default -- they both leave them packed in the extensions directory and extract files from them as needed. userChromeJS expects the README.txt file to be available to copy into userChrome.js, but it's not there because it's in the XPI. I'm not sure what the proper fix is, but something needs to be done. People installing userChromeJS for the first time are having trouble finding userChrome.js to edit it (since it's not there!).
Quick fix. add the following line to the install.rdf in the XPI:
Firefox 16 broke userChrome.js and a bunch of other extensions when it comes to popups and the load event. In Firefox 15 a userChrome.js with the following code will produce an alert for popup windows, but in 16 I get nothing:
var appcontent = window.document.getElementById("appcontent"); if (appcontent) appcontent.addEventListener("DOMContentLoaded", function(e) { var document = e.target; if (!document.location) return; var href = document.location.href; alert(href); }, false);
Comments in bug 799348 make it sound like the preferred way of listening for an opened chrome window is to use the chrome-document-global-created observer. I replaced domwindowopened with that in components/userChrome_js.js and the above works again. I'm not sure when the chrome-document-global-created observer was added, but I assume there will be some compatibility issues for older products..
They checked in a fix for Firefox 19 but that's a way off yet and I guess there's some concern about breakage elsewhere, so I have no idea if they'll check this in to earlier future releases. Since this breaks Firebug and even the new builtin developer toolbar, maybe they'll get on this sooner rather than later.
Just thought I'd mention something here in case it wasn't on the radar already.
The problem described earlier in this thread with modified userChrome.js files not being loaded when you restart Firefox or Thunderbird, unless you delete the startupCache or use one of the other workarounds described above, doesn't appear to have been fixed. Is there a way to fix it within the userChromeJS extension, or does it require a fix in the Mozilla core?
there's no fix because there's no bug. this is an advanced tool (despite people using it to run privileged code without knowing code) and the -purgecaches flag is the correct way to handle changes by testers. permanently defeating the cache is incorrect.
Can userChromeJS be used to affect the modal and sizemode properties of a dialog box? For example, I would like to make the Thunderbird Account Settings dialog, AccountManager.xul, not be modal, and I would also like it to open maximized and to have min/max buttons. Is that possible? Thanks a lot
mozillaZine is an independent Mozilla community and advocacy site. We're not affiliated or endorsed by the Mozilla Corporation but we love them just the same.