Closed
Bug 221503
Opened 21 years ago
Closed 21 years ago
an empty Personal Toolbar causes the browser window to continually vibrate
Categories
(SeaMonkey :: Bookmarks & History, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: pete, Assigned: neil)
References
Details
Attachments
(4 files)
5.60 KB,
text/plain
|
Details | |
947 bytes,
patch
|
janv
:
review+
alecf
:
superreview+
|
Details | Diff | Splinter Review |
1.43 KB,
patch
|
p_ch
:
review+
alecf
:
superreview+
|
Details | Diff | Splinter Review |
1.55 KB,
patch
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030925
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030925
Mozilla doesn't install out-of-the-box on Windows the way I'd like it to behave
for the people I install it for. If I'm installing Mozilla for more than 2
people I want to automate the process of configuration; I expect a lot of people
are doing this so I think its important that pre-configuration works and is easy
to understand. I'm installing it for perhaps a hundred people, so I definately
need to automate the configuration.
Pre-configuration needs to be made using Mozilla's program-wide settings,
because thats what pre-configuration is all about and because from a Windows
batch script we can't make settings in users' profiles as their location is
unknowable due to the directory salting.
One part of the configuration I want to make is removing the 'Home' button from
the Personal Toolbar. To do this I insert this line at the bottom of
%PROGRAMFILES%\Mozilla\defaults\pref\all.js (using a batch script):
pref("browser.toolbars.showbutton.home", false);
But this only removes the tick in the box in the preferences dialog, it doesn't
actually stop the button from showing. To actually stop the button from showing
I have to edit %PROGRAMFILES%\Mozilla\defaults\profile\US\localstore.rdf.
In Mozilla 1.3 and 1.4 I had to add this to the bottom of localstore.rdf, before
the '</RDF:RDF>':
<RDF:Description about="chrome://navigator/content/navigator.xul">
<NC:persist resource="chrome://navigator/content/navigator.xul#main-window"/>
<NC:persist resource="chrome://navigator/content/navigator.xul#home-button"
hidden="true" />
</RDF:Description>
(I put other sections in there too to remove other buttons but I'm just keeping
this report to the Home button for simplicity)
This method doesn't work in Mozilla 1.5RC2. In Mozilla 1.5RC2 the syntax appears
to have changed to:
<RDF:Description about="chrome://navigator/content/navigator.xul#home-button"
hidden="true" />
(I don't understand RDF, I've just culled my understanding from reading the
files themselves; when I first learned to pre-configure Mozilla way back there
wasn't any documentation to read)
If I insert into localstore.rdf using this syntax instead then it still doesn't
remove the Home button.
So, how do I pre-configure this aspect of Mozilla in 1.5?
(this change doesn't appear to have been documented in Bugzilla)
Reproducible: Always
Steps to Reproduce:
Summary: pre-configuring Personal Toolbar buttons with localstore.rdf has changed in 1.5 → pre-configuring Personal Toolbar buttons with localstore.rdf differs in 1.5
.
Assignee: ccarlen → neil.parkwaycc.co.uk
Component: Preferences: Backend → XP Apps: GUI Features
Assignee | ||
Comment 2•21 years ago
|
||
The following syntax is absolutely correct localstore RDF. IMHO anything else is
just plain wrong, and was never guaranteed to work.
<RDF:Description about="chrome://navigator/content/navigator.xul">
<NC:persist resource="chrome://navigator/content/navigator.xul#home-button" />
</RDF:Description>
<RDF:Description about="chrome://navigator/content/navigator.xul#home-button"
hidden="true" />
Marvellous, that works, thanks Neil.
I take responsibility for the way I've gone about this, copying from existing
files without understanding the code, that if it works but shouldn't then it may
break in future.
As an aside, it would be useul if changes between Mozilla releases to all.js,
editor.js, localstore.rdf, panels.rdf etc could be documented for people who're
pre-configuring using them (i.e. there were additions to localstore.rdf in
Mozilla 1.4 compared with 1.3, for 'sidebar-box' and 'sidebar-splitter')
should I file another bug to the effect that 'browser.toolbars.showbutton.home'
and others like it cannot be used to actually remove buttons?
in the future you should consider swiping the localstore.rdf from a
profile and putting it into defaults (you can redact it first).
I don't know why I thought Neil's code worked, as it doesn't. It still makes the
window bounce up and down. I can only get the window to stay still if I use:
RDF:Description about="chrome://navigator/content/navigator.xul">
<NC:persist resource="chrome://navigator/content/navigator.xul#home-button" />
<NC:persist resource="chrome://navigator/content/navigator.xul#go-button" />
<NC:persist resource="chrome://navigator/content/navigator.xul#bookmarks-button" />
/RDF:Description>
<RDF:Description about="chrome://navigator/content/navigator.xul#home-button"
hidden="true" />
</RDF:Description>
<RDF:Description about="chrome://navigator/content/navigator.xul#go-button"
hidden="true" />
</RDF:Description>
<RDF:Description about="chrome://navigator/content/navigator.xul#bookmarks-button"
hidden="true" />
</RDF:Description>
and then I'm still left with the Bookmarks button on the Personal Toolbar. Am I
missing something?
Comment 6•21 years ago
|
||
goldenear: could you attach your the localstore.rdf to see it is well formed?
and btw, why don't you delete it before installing?
this is what I'm currently using and it causes the browser window to jump up
and down
"and btw, why don't you delete it before installing?"
delete it from Mozilla's program directory? I do
delete the user's version from their profile directory? I have a batch script
and I use that to wipe out the profile before testing
Assignee | ||
Comment 9•21 years ago
|
||
Aha! Is this because when Mozilla opens a browser window without the bookmarks
or home buttons, there are no buttons at all on the personal toolbar, until the
bookmarks finish loading, when suddenly there are, thus changing the size of the
personal toolbar?
Reporter | ||
Comment 10•21 years ago
|
||
the problem is that the browser window bounces up and down continuously, until
its closed down.
I'm also wiping out the bookmarks using a pre-configured bookmarks.html, which
is stripped down and doesn't include anything on the Personal Toolbar.
if you want to check it out, the script is included in TWEAK which you can
checkout at http://thegoldenear.org/tweak/. but I've tried this with and without
my changes to bookmarks.html and nailed it down to when I only change
localstore.rdf. can anyone reproduce it using the attached localstore.rdf?
Assignee | ||
Comment 11•21 years ago
|
||
OK, so there are two issues at work here:
1. The resizeFunc is called on content resize as well as chrome resize
2. The resizeFunc also needs to early return when there are no bookmarks
Patch coming up.
Status: NEW → ASSIGNED
Component: XP Apps: GUI Features → Bookmarks
Assignee | ||
Comment 12•21 years ago
|
||
Assignee | ||
Updated•21 years ago
|
Attachment #132992 -
Flags: superreview?(alecf)
Attachment #132992 -
Flags: review?(varga)
Comment 13•21 years ago
|
||
Comment on attachment 132992 [details] [diff] [review]
Proposed patch
r=varga
Attachment #132992 -
Flags: review?(varga) → review+
Reporter | ||
Comment 14•21 years ago
|
||
Will this make it into 1.5?
Comment 15•21 years ago
|
||
Comment on attachment 132992 [details] [diff] [review]
Proposed patch
sr=alecf
Attachment #132992 -
Flags: superreview?(alecf) → superreview+
Assignee | ||
Comment 16•21 years ago
|
||
Fix checked in to the trunk.
If you want this in 1.5 set approval1.5 to ? and make your case to drivers.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Comment 17•21 years ago
|
||
The bouncing that is mentioned in comment 10, is that the same as in bug 219643,
bug 221725 and bug 221779 ?
Comment 18•21 years ago
|
||
Neil: good catch
Thought, this patch has two flaws:
- the first one: you bail in |resizeFunc| without unsetting the flag
|_overflowTimerInEffect|. That means that if you move out all the bookmarks in
the BT, then it will no more be possible to have the chevron back.
- then, more importantly, it breaks the reinitializing of the bookmarks toolbar
when its elements are reordered via the sidebar, the bm, etc...
Even if there is no argument in the setTimouts in the bookmarksToolbarMenu
observer, |event| is not null in |resizeFunc|, as you assumed.
That's because of the the "secret" argument that is added to function called via
the timer:
http://lxr.mozilla.org/seamonkey/source/dom/src/base/nsGlobalWindow.cpp#5003
You should simply force the null argument in the observer.
Assignee | ||
Comment 20•21 years ago
|
||
pch, thanks for the lowdown on setTimeout
Assignee | ||
Comment 21•21 years ago
|
||
Comment on attachment 133027 [details] [diff] [review]
Supplementary patch
OK, so hopefully this fixes the timer issues.
Attachment #133027 -
Flags: superreview?(alecf)
Attachment #133027 -
Flags: review?(p_ch)
Comment 22•21 years ago
|
||
Comment on attachment 133027 [details] [diff] [review]
Supplementary patch
I think you should unset |_overflowTimerinEffect| at the very beginning of
|resizeFunc|. If |bookmarks-ptf| is hidden, then a modification of the
resources in the personal toolbar will still prevent the chevron from working
if the user unhide it. (but that was a bug prexisting your patch)
with that r=me.
Attachment #133027 -
Flags: review?(p_ch) → review+
Comment 23•21 years ago
|
||
err, my last comment is not correct, since the observer goes away with the
bookmarks toolbar. But I still think it's better practice.
Assignee | ||
Comment 24•21 years ago
|
||
pch: well not right at the top, after the event check surely?
Comment 25•21 years ago
|
||
Comment on attachment 133027 [details] [diff] [review]
Supplementary patch
sr=alecf
Attachment #133027 -
Flags: superreview?(alecf) → superreview+
Comment 26•21 years ago
|
||
It is safe to assume that only a resize event can bail in the event check.
But I was thinking that putting the line on top would prevent people from
putting additional checks before unsetting the flag but I don't have a so strong
opinion. Do what you want.
Assignee | ||
Comment 27•21 years ago
|
||
Assignee | ||
Comment 28•21 years ago
|
||
I hope I got it right this time :-[
Status: REOPENED → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → FIXED
Summary: pre-configuring Personal Toolbar buttons with localstore.rdf differs in 1.5 → an empty Personal Toolbar causes the browser window to continually vibrate
Blocks: 219643
Reporter | ||
Comment 30•21 years ago
|
||
my localstore.rdf method of pre-configuration is now working as expected.
tho it may be obvious why this happens to those of you that understand the
source, I thought I'd mention it just in case its useful to know... in testing I
found that having configured the 1.6a build 2003101304 to have nothing on the
Personal Toolbar, then uninstall that version and install 1.5RC2, using the same
profile, 1.5RC2 had the empty Personal Toolbar that didn't bounce up and down,
until an item was manually added then removed from it
Assignee | ||
Comment 31•21 years ago
|
||
Yes, I'd found that some operations start the bouncing and others stop it.
Updated•21 years ago
|
Flags: blocking1.5?
Comment 32•21 years ago
|
||
*** Bug 230084 has been marked as a duplicate of this bug. ***
Comment 33•21 years ago
|
||
*** Bug 226186 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Product: Browser → Seamonkey
Comment 34•19 years ago
|
||
*** Bug 306716 has been marked as a duplicate of this bug. ***
You need to log in
before you can comment on or make changes to this bug.
Description
•