In Contents | Customizing Mozilla | Toolbars | Status Bar, there should be an image of the cookie notification icon, but instead the alternate text is shown. The URI for the image should be "chrome://communicator/skin/cookie/taskbar-cookie.gif", and not "chrome://cookie/content/taskbar-cookie.gif".

Comment on attachment 152272 [details] [diff] [review] Patch we can't use chrome://*/skin/* path, because every theme name its files differently. A new approach is needed

Do you mean we should always show one version of this icon? Even though it may confuse users with other themes?

Comment on attachment 152272 [details] [diff] [review] Patch > we can't use chrome://*/skin/* path, because every theme name its files > differently. A new approach is needed That is true, but that is the current process. If you want that changed, file another bug. I believe that this is something that would require debate.

--> hasse

Hmm... Looks like this never got checked in. Hasse, any chance you could update the patch? Neil, can you check in the patch once it has been updated?

I won't check this in, because I agree with comment 2.

But since we have no alternative now, and since this chrome:// usage is spread in at least other 5 files, why not fix it now and then replace with a real solution? AFAIK no one popped up with a proposal or something for years...

Also, another wrong entry is in customize_help.xhtml, line 692. "communicator/skin" occurs in 18 other places, to be precise... ;)

I guess this can be used to start fixing the bug as Neil suggested over IRC. A red circle/ellipse (as used elsewhere) should be added to relevant parts to remove references to chrome/skin. Comments welcome.

Worked on the issue somewhat... IMHO the only images worth adding are taskbar-cookie (actually the name should be statusbar-cookie), referenced 5 times, and bookmark-item, referenced 7 times. online and offline gifs can be transformed into referencing the already shipped png versions. The references to pg-[portait|landscape]-small.gif are already broken (nav_help.xhtml, lines 930, 933, 965, 969). I wouldn't create images fo showing the different locks images (secure, insecure, broken). I've been playing with the turbo-systray.gif image, and after converting it to png (saving more than 1KB), I realized it is Win only, so there's no real point in moving it to the images dir. SUggestions and/or comments?

While at it, I converted the chrome->on/offline.gif to the images/*.png versions and catched a few still unconverted " (-> <q></q>).

Please verify that this is ok.

Please check this one also.

Same patch, but also converted the last few " (not even &quot;!!) to <q> form: once and for all.

Ouch! I just noted that I should have added the two new images to the jar.mn file, so that they can be added to the package. Will attach a patch for this ASAP...

Have you opened another bug for the long term fix for the underlying problem? If so what is its number?

> I've been playing with the turbo-systray.gif image, > and after converting it to png (saving more than 1KB), I realized it is Win > only, so there's no real point in moving it to the images dir. SUggestions > and/or comments? <img class="win">??

(In reply to comment #18) > Have you opened another bug for the long term fix for the underlying problem? > If so what is its number? There was a bug (probably a meta one, not directly referencing the problem) which has some comments on the issue. rlk had some kind of solution sort of working, but he never submitted it before leaving for other duties: probably Stefan or Neil will remember where. I tried a search but didn't find anything useful. (In reply to comment #19) > <img class="win">?? It's already in a win only section: as Neil suggested to remove references to chrome, I was going to convert all such references to images to be put into the images help dir and reference those instead. I don't think this image is worth the effort, since it's Win only.

This is my understanding of how to add xul elements to the help pages. You will need to add the xul namespace by adding the following line to the <html> element: xmlns:xul="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" This will then allow you to add <xul:menuitem class="menuitem-iconic bookmark-item" label="Mozilla"/> for example as long as you add the relevant style sheet, chrome://communicator/skin/bookmarks/bookmarks.css in this case. Another example is <xul:statusbarpanel class="statusbarpanel-iconic" id="privacy-button"/> and using the stylesheet chrome://navigator/skin/navigator.css

Thanks to a very helpful Ian, here's a first attempt at using XUL inside help files. Comments are welcome, as would be a way to put some background color to the on/offline icons, which look particularily bad as it is.

Here's the component bar with it's icons/buttons. Some work remains, though. Need to highlight the different components. Using a <stack> containing one hbox (with borders) and a component seems to work with Classic and Pinstripe, but not with the Modern theme

Try style="-moz-outline: 2px solid red; -moz-outline-radius: 50%;"

> Try style="-moz-outline: 2px solid red; -moz-outline-radius: 50%;" ah, thx Neil :) Looks quite ok on my three themes (Classic, Pinstripe & Modern). Looks best on Classic. Had to use a <stack> to make it look ok on my Modern. Looks better without the radius, though. Perhaps it is enough with a square?

Comment on attachment 166629 [details] New version of Component Bar I have to say I prefer it round...

I attach the work I've done on the Location Bar. Still some issues, though.

For the dropmaker error, try <xul:window> <xul:stack> <xul:spacer/> <xul:hbox> <!-- stuff here --> </xul:hbox> </xul:stack> </xul:spacer> That should also fix the preventDefault() workaround.

Forget that. We can just turn off JavaScript in help. helpBrowser.docShell.allowJavascript = false;

Status Bar with icons - attaching what I've done so far.

See http://lxr.mozilla.org/seamonkey/source/extensions/p3p/resources/content/p3pSummary.js#54

I have a Location Bar and a mail thread pane here: http://hem.fyristorg.com/s_her/help-xbl-test.xhtml Note that the code in the xbl file isn't cleaned up yet (css should be somewhere else etc etc). Any feedback on how it looks on your os/themes are welcome. iirc there was some issue with the mail thread pane in some theme? Should the css go in helpfileLayout.css or do we want a separate file?

Is help-test-final.xml altered from the original .xml files or this just so the web page can be displayed? The page displays fine in classic on windows xp.

(In reply to comment #33) > Created an attachment (id=174832) [edit] > Here is how it looks like under linux+modern, current trunk > Notice that the horizontal line in modern on linux (and also happens in windows) which should below the the dropdown's box is too high and runs through it.

Presumably once we've got a resolution to the locale binding's scripts running when JS is disabled bug we can lose the -moz-binding: none; styles?

(In reply to comment #36) > Presumably once we've got a resolution to the locale binding's scripts running > when JS is disabled bug we can lose the -moz-binding: none; styles? Yeah, if bug 277836 gets fixed... If bug 280120 gets fixed we can remove some ;)

> Notice that the horizontal line in modern on linux (and also happens in windows) > which should below the the dropdown's box is too high and runs through it. OK, new version at the same address: http://hem.fyristorg.com/s_her/help-xbl-test.xhtml

(In reply to comment #38) > > Notice that the horizontal line in modern on linux (and also happens in windows) > > which should below the the dropdown's box is too high and runs through it. > > OK, new version at the same address: > http://hem.fyristorg.com/s_her/help-xbl-test.xhtml > Looks fine in modern and classic for me now on windows.

OK, since we now can turn off js in help... This looks ok in classic/modern on mac. iirc, I had an issue with it in the mozilla pinstripe theme, the focused tab was blue (shouldn't). But that theme is quite broken in Help anyway ;)

Would be nice to try and get a fix in for taskbar-cookie.gif as I broke it with the landing of bug 277097.

(In reply to comment #41) > Would be nice to try and get a fix in for taskbar-cookie.gif as I broke it with > the landing of bug 277097. Working on it...

Some explantions/comments: 1) <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"[ + <!ATTLIST span value NMTOKEN #IMPLIED > <!ENTITY % brandDTD SYSTEM "chrome://branding/locale/brand.dtd" > %brandDTD; ]> Since I wanted to use xbl inheritance in some of the bindings, i needed a new attribute for the <span>:s. 2) The css file looks really ugly, all kinds of intendation styles... I didn't really know what style to follow. Perhaps it's time for some clean-up in another bug? 3) I had some trouble with the security icons in mail_sec_help, had to keep the tables and even set the width on the cells in one of the tables. I think it will do fine for the moment, though. It also seems that the wrong icons were used (same icons for message headers and compose window). Those should be ok now, but I have only verified it by looking at the source files.

Comment on attachment 178689 [details] [diff] [review] Patch for 15 icons in Help >--- /dev/null Sat Mar 26 23:01:18 2005 >+++ extensions/help/resources/content/help.xml Sat Mar 26 23:00:53 2005 >+ <binding id="popup-blocked" extends="#status-bar-base"> >+ <content> >+ <xul:window> >+ <xul:statusbarpanel id="popupIcon" class="statusbarpanel-iconic"/> >+ </xul:window> >+ </content> >+ </binding> Will this live in a xul:iframe? If not, is the xul:window part really needed? >--- extensions/help/resources/locale/en-US/helpFileLayout.css 28 Oct 2004 11:11:28 -0000 1.8 >+++ extensions/help/resources/locale/en-US/helpFileLayout.css 26 Mar 2005 22:20:05 -0000 >+* { -moz-user-input: none; } >+ Hmm, would this potentially break user selection of text? >@@ -188,11 +189,12 @@ > </li> > <li>Choose the signing certificate you want to use, then click OK.</li> > <li>Follow the same steps under Encryption: click the Select button, select >- the encryption certificate you want to use, and click OK.</li> >+ the encryption certificate you want to use, and click OK. > > <p>In some cases you may be able to specify the same certificate under > Encryption that you specified under Digital Signing; check with your system > administrator to find out for sure.</p> >+ </li> > </ol> Why this change? >Index: extensions/help/resources/locale/en-US/using_certs_help.xhtml >=================================================================== >RCS file: /cvsroot/mozilla/extensions/help/resources/locale/en-US/using_certs_help.xhtml,v >retrieving revision 1.48 >diff -u -r1.48 using_certs_help.xhtml >--- extensions/help/resources/locale/en-US/using_certs_help.xhtml 10 Mar 2005 18:44:00 -0000 1.48 >+++ extensions/help/resources/locale/en-US/using_certs_help.xhtml 26 Mar 2005 22:20:09 -0000 >@@ -2,6 +2,7 @@ > > <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" > "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"[ >+ <!ATTLIST span value NMTOKEN #IMPLIED > > <!ENTITY % brandDTD SYSTEM "chrome://branding/locale/brand.dtd" > > %brandDTD; > ]> >@@ -96,20 +97,17 @@ > > <table summary="lock icons"> > <tr> >- <td><img alt="closed lock icon" >- src="chrome://communicator/skin/icons/lock-secure.gif"/></td> >+ <td><span class="securityStatus" value="high"/></td> > <td>A closed lock means that the page was protected by encryption when it > was received.</td> > </tr> > <tr> >- <td><img alt="open lock icon" >- src="chrome://communicator/skin/icons/lock-insecure.gif"/></td> >+ <td><span class="securityStatus"/></td> > <td>An open lock means the page was not protected by encryption when it was > received.</td> > </tr> > <tr> >- <td><img alt="broken lock icon" >- src="chrome://communicator/skin/icons/lock-broken.gif"/></td> >+ <td><span class="securityStatus" value="broken"/></td> > <td>A broken lock means that some or all of the elements within the page > were not protected by encryption when the page was received, even though > the outermost HTML page was encrypted.</td> >Index: extensions/help/resources/locale/en-US/using_priv_help.xhtml >=================================================================== >RCS file: /cvsroot/mozilla/extensions/help/resources/locale/en-US/using_priv_help.xhtml,v >retrieving revision 1.55 >diff -u -r1.55 using_priv_help.xhtml >--- extensions/help/resources/locale/en-US/using_priv_help.xhtml 10 Mar 2005 18:44:00 -0000 1.55 >+++ extensions/help/resources/locale/en-US/using_priv_help.xhtml 26 Mar 2005 22:20:09 -0000 >@@ -522,8 +521,7 @@ > <a href="#stored_cookies">Stored Cookies</a> tab.</p> > > <p>When a cookie is first flagged, the Cookie Manager displays the cookie >- notification icon (<img alt="cookie notification icon" >- src="chrome://cookie/content/taskbar-cookie.gif"/>) near the >+ notification icon (<span class="cookieNotification"/>/>) near the looks like malformed xml there |/>/>|

(In reply to comment #44) > (From update of attachment 178689 [details] [diff] [review] [edit]) > >--- /dev/null Sat Mar 26 23:01:18 2005 > >+++ extensions/help/resources/content/help.xml Sat Mar 26 23:00:53 2005 > >+ <binding id="popup-blocked" extends="#status-bar-base"> > >+ <content> > >+ <xul:window> > >+ <xul:statusbarpanel id="popupIcon" class="statusbarpanel-iconic"/> > >+ </xul:window> > >+ </content> > >+ </binding> > > Will this live in a xul:iframe? If not, is the xul:window part really needed? Without the xul:window part, of the statusbarpanel icons background-color is white and that looks a bit odd, since you can see a tiny border around the icons then. You can see how it looks without xul:window here: http://hem.fyristorg.com/s_her/help-xbl-test-final.xhtml If you use xul:window, the background-color will be the same as the statusbarpanel. The lock icons look like they would work without xul:window, but I'm afraid what other theme authors do ;) I haven't found any method to use the the two small icons in mail_sec_help (signature/encryption) without <xul:window> either, since they're bound to the msgcomposeWindow in the original css file (msgCompSMIMEOverlay.css) > >+* { -moz-user-input: none; } > >+ > > Hmm, would this potentially break user selection of text? I haven't seen this. On my test-build I was able to select text. > >@@ -188,11 +189,12 @@ > > </li> > > <li>Choose the signing certificate you want to use, then click OK.</li> > > <li>Follow the same steps under Encryption: click the Select button, select > >- the encryption certificate you want to use, and click OK.</li> > >+ the encryption certificate you want to use, and click OK. > > > > <p>In some cases you may be able to specify the same certificate under > > Encryption that you specified under Digital Signing; check with your system > > administrator to find out for sure.</p> > >+ </li> > > </ol> > > Why this change? I noticed that my editor complained :) I don't think you can have paragraphs between list-items. They have to be inside the list-items. Looking at the file, I believe there are more of these. At least the w3c validator complains. > >+ notification icon (<span class="cookieNotification"/>/>) near the > looks like malformed xml there |/>/>| > Aagh, sorry. Will fix that.

Here's a new version without the extra "/>".

Comment on attachment 179064 [details] [diff] [review] 15 icons in Help without incorrect "/>" >--- /dev/null Sat Mar 26 23:01:18 2005 >+++ extensions/help/resources/content/help.xml Sat Mar 26 23:00:53 2005 >@@ -0,0 +1,145 @@ >+<?xml version="1.0"?> >+ >+<!-- ***** BEGIN LICENSE BLOCK ***** >+ - Version: MPL 1.1/GPL 2.0/LGPL 2.1 >+ - >+ - The contents of this file are subject to the Mozilla Public License Version >+ - 1.1 (the "License"); you may not use this file except in compliance with >+ - the License. You may obtain a copy of the License at >+ - http://www.mozilla.org/MPL/ >+ - >+ - Software distributed under the License is distributed on an "AS IS" basis, >+ - WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License >+ - for the specific language governing rights and limitations under the >+ - License. >+ - >+ - The Original Code is Mozilla Communicator client code, released. >+ - March 31, 1998. >+ - >+ - The Initial Developer of the Original Code is >+ - Netscape Communications Corporation. >+ - Portions created by the Initial Developer are Copyright (C) 1998-2000 >+ - the Initial Developer. All Rights Reserved. I doubt netscape wrote this :) You probably want to change the part about the original code to something like this: The Original Code is Mozilla Help code. The initial developer is you too :) r=me, applied and seems to work fine.

Moving to suite Help component.

This version is using "good" css (xx.classname --> .classname). Also removed the unused #search-button and changed a classname. Transfering dorons r+.

Just updating the mail_help diff in order to prevent bitrot, some hunks were offset...

Comment on attachment 185433 [details] [diff] [review] 15 icons in Help - updated to prevent bitrot So... one problem here is that certain "images" won't show up if you don't install/build the whole suite. In this particular patch css files in "chrome://messenger..." won't exist if you choose to not install mailnews. Neil, what do you think? Shall we just do the parts that will always work (only refer to stuff in chrome://navigator..." etc etc) now and wait for Help to be fixed so only docs relevant to what you actually have installed will be shown (bug needs to be filed)?

Comment on attachment 185433 [details] [diff] [review] 15 icons in Help - updated to prevent bitrot > So... one problem here is that certain "images" won't show up if you don't > install/build the whole suite. In this particular patch css files in > "chrome://messenger..." won't exist if you choose to not install mailnews. Actually, I was wrong. I've made a build with --disable-mailnews and the 5 icons that comes from skin/messenger still show up. Neil you're right, it appears that the skin folders are included. But there is a problem here, though. Opening the "Signing & Encrypting Messages" section in Help will produce a warning in my debug build: 'WARNING: chrome: failed to get base url for chrome://messenger/content/messenger.css -- using wacky default, file /Users/Stefan/Mozilla-projekt/kod/mozilla/rdf/chrome/src/nsChromeRegistry.cpp, line 525' In the patch I use 2 stylesheets in 'skin/messenger/smime' to get the signing/encryption icons. Both the stylesheets imports the 'messenger/skin/messenger.css' file. This file tries to import 'messenger/content/messenger.css'.

Same patch as the previous one but without the messenger part. Changed a year in the license text in the new file as well. Transferring dorons r+.

Can we change for cookie notification icon? <img src="chrome://cookie/content/taskbar-cookie.gif" alt="cookie notification icon"/>: to: <img src="chrome://communicator/skin/permissions/taskbar-cookie.gif" alt="cookie notification icon"/>: in: using_priv_help.xhtml customize_help.xhtml

Patch with changed URI for taskbar-cookie.gif icon as described in previous comment.

Comment on attachment 246614 [details] [diff] [review] Patch with changed URI for taskbar-cookie.gif icon. You are using the attic versions, suite help is now under /suite/locales/en-US/chrome/common/help so could you please create a diff from there. Your diff also had a tab in.

Sorry for last patch from attic. This I made from trunk.

Comment on attachment 246720 [details] [diff] [review] Patch with changed URI for taskbar-cookie.gif icon - diffs from trunk (checked in to trunk). You probably ment iann_bugzilla ;-)

SOmeone will need to check this in on trunk, and personaly I'd like to see this going on branch as well: what about having some better looking docs for 1.1? The burden for localizers is minor, since it means fixing just a few links, so it doesn't add to the amount of stuff to translate.

Comment on attachment 246720 [details] [diff] [review] Patch with changed URI for taskbar-cookie.gif icon - diffs from trunk (checked in to trunk). I landed this on trunk

Morphing the summary since I don't want to open a new bug...

This is basically attachment #185433 [details] [diff] [review] updated to current tip - also includes the feedicon that was recently added. I forgot to remove the obsolete icons, though. I'm just putting it here, it's not tested enough yet. Also, we should probably think through this because I'm not sure it's possible to do *all* images. Icons are straight-forward, some buttons might be doable, but larger ui-elements might be difficult to do.

Comment on attachment 387289 [details] [diff] [review] Updated patch (with feedicon xbl) OK, so I've just noticed that the new/close tab buttons doesn't work. The xul have probably changed.

chrome://communicator/skin/cookie/taskbar-cookie.gif does not exist in SeaMonkey 2.1pre :P In fact I don't think that the statusbar cookie panel still exists. That help section should just be deleted.

(In reply to comment #61) > Morphing the summary since I don't want to open a new bug... I thought that Stefan had morphed this to a more general bug on using XBL for icon representations in the help content, now you're morphing it back to the cookie issue (which no longer exists), meaning Stefan should indeed open a bug on the XBL binding for all other cases where icons are displayed in the help context, or do you just want to morph this back to the previous title and open a new bug on removing the cookie section which does no longer apply?

(In reply to comment #64) > In fact I don't think that the statusbar cookie panel still exists. That help > section should just be deleted. Probably went away when p3p did, or something...

This bug is about replacing the help icons with xbl. Please open a new bug for removing the cookie selection. Thanks.

Philip didn't cc himself so I don't think he have seen comment #65, comment #66 and comment #67.

(In reply to comment #67) > removing the cookie selection. Erm, should be "removing the cookie section"

> This bug is about replacing the help icons with xbl. Please open a new bug for > removing the cookie selection. Thanks. I thought you had given up on the XBL stuff? No change in two years after all.