[Ext] Console² 0.1 to 0.3.6.2

[mcm_ham]

Might want to fix the german locale, which can be tested by changing the general.useragent.locale under about:config to de-DE.

[old zeniko]

Might want to fix the german locale, which can be tested by changing the general.useragent.locale under about:config to de-DE.

Why, what's wrong with it?

[mcm_ham]

Usual story incorrect encoding or missing/invalid locale entry. If you want to some extensions make use of a fall back position in case of error:

Code: Select all

<!DOCTYPE overlay [
<!ENTITY % console2 SYSTEM "chrome://console2/locale/console2.dtd" >
%console2;
<!ENTITY % console2FB  SYSTEM "chrome://console2/content/en-US/console2.dtd" >
%console2FB;
]
>

But of course it requires the fall back locale to be under content since "chrome://console2/locale/en-US/" doesn't exist.

[old zeniko]

I can't reproduce this. The entitites are all present (I've got an automated check which ensures that all locales feature the exact same entities as the en-US locale), especially so the entity in question (&console.title;). Anyway, changing the locale on my system works flawlessly. Does this problem appear also on a clean profile with only Console² installed?

EDIT: I've found the bug. The path the to locale in the manifest was wrong (which I didn't notice since I use a different manifest for developing). Thanks for the notification.

[Peter(6)]

with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1 ID:2005100614
i get a warning popping up in EM:

Code: Select all

Firefox could not install the file at:
http://www.haslo.ch/zeniko/software/console2.xpi
because: invalid file hash (possible download corruption)

when i try to update to version 0.2.2

[Peter(6)]

@Zeniko
thanks for the quick fix
0.2.2.1 installed w/o a problem

[old zeniko]

It's probably a bad idea of doing download verification with hashes when the file changes often (since either the file or the update.rdf might be stuck in a cache somewhere). Anyway, this should be a WFM with a clean cache.

I suppose that's the price you pay for being hip and using the latest features... any suggestions for how to handle this in the future? Would this be worth a bug (skip cache for extension and update.rdf, when update.rdf contains an updateHash entry)?

[Peter(6)]

I asked Robert_Strong to have a look at this later

[Mook]

Would it be possible to change line 65 of console2.css (.console-row[selected="true"])from background: to, say, background-image:? On the default Windows classic / winstripe, the former ends up having the selected items be white text on a light blue background, as the CSS rules end up being something like

background-image: url("chrome://mozapps/skin/shared/itemSelected.png"); /* a mostly transparent image */
background-color: transparent; /* due to the background: resetting background-color */
color: highlighttext; /* richlistbox.css line 60, richlistbox:focus > richlistitem[selected="true"] - for me, white*/

The element below, <richlistbox id="ConsoleBox">, has background-color: -moz-field due to richlistbox.css

(Was this a recent change? I don't recall seeing this for 0.2... but then I've been through a reformat since and could just have faulty memory )

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051007 Firefox/1.6a1
Console² 0.2.2.1 (from EM's auto-update; previously 0.2.1 IIRC but never got a chance to actually use that)

[Philip Chee]

It's probably a bad idea of doing download verification with hashes when the file changes often (since either the file or the update.rdf might be stuck in a cache somewhere).
[... ]
any suggestions for how to handle this in the future?

pragma nocache on the server?

[old zeniko]

@Mook: Theming is definitely not my thing. Anyway, we'd have two possibilities here: either go with what you'd expect from elsewhere and use HighLight as background-color (and drop the blue veil) or try to copy the Extensions manager and overwrite the definitions in richlistbox.css with the colors of the richlistbox itself (-moz-Field, -moz-FieldText). From what I'm used to, I'd prefer the second one. What do you say: <a href="http://www.haslo.ch/zeniko/software/console2-dev.xpi">Console² 0.2.2.1+</a>?

@Philip: Would probably be a good idea, but you'd have to tell me how to do that in a .htaccess on a fairly restricted server (at least the Header directive seems not to work).

Anyway, I'd rather see Firefox do it right at the cost of two HEAD requests (no need to get the files again if the Last-modified date hasn't changed) than having to write my own .htaccess file.

[Robert S.]

It's probably a bad idea of doing download verification with hashes when the file changes often (since either the file or the update.rdf might be stuck in a cache somewhere). Anyway, this should be a WFM with a clean cache.

I suppose that's the price you pay for being hip and using the latest features... any suggestions for how to handle this in the future? Would this be worth a bug (skip cache for extension and update.rdf, when update.rdf contains an updateHash entry)?

An easy way to deal with this for authors that update their extension repeatedly in a short timeframe (also in general) is to use a different filename so it doesn't try to retrieve it from the cache. Perhaps sometime after 1.5 it will be possible to prevent Firefox from reading from the cache for the xpi's.

btw: For the update rdf the EM already sets no-cache in the headers when retrieving the rdf but it is a good idea to configure the server properly so the client doesn't cache the rdf or anything else you don't want to be in the cache

[old zeniko]

The most recent <a href="http://www.haslo.ch/zeniko/software/console2-dev.xpi">testing version</a> (v0.2.3+) finally uses coherent artwork from the pinstripe theme (which will soon land for Firefox 1.5 - see <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=291002">bug 291002</a>). I've also looked into the proposals from <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=312962">bug 312962</a>, but I don't like any of them enough for including them.

Two notes: Better don't even try to use small icons for the taskbar - I've got no small icons and Gecko does a lousy job when resizing them. And from now on, the current nightly will also be linked from the homepage.

[gemal]

I really miss having the clear button available without having to use the menu. Any chance you could move the Clear button outside the submenu?

[Schrade]

gemal: Right click on the toolbar in the Error Console Window, select Customize, drag the Clear button to the toolbar. There's your clear button!

This was sort of a secret until it was mentioned several posts ago.