MozillaZine

[Ext] Console² 0.1 to 0.3.6.2

Announce and Discuss the Latest Theme and Extension Releases.
mcm_ham

User avatar
 
Posts: 1747
Joined: June 16th, 2004, 6:09 am
Location: Christchurch, New Zealand

Post Posted October 7th, 2005, 4:59 pm

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
 
Posts: 0
Joined: December 31st, 1969, 5:00 pm

Post Posted October 8th, 2005, 1:29 am

mcm_ham wrote: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

User avatar
 
Posts: 1747
Joined: June 16th, 2004, 6:09 am
Location: Christchurch, New Zealand

Post Posted October 8th, 2005, 2:05 am

Image

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
 
Posts: 0
Joined: December 31st, 1969, 5:00 pm

Post Posted October 8th, 2005, 2:26 am

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)

User avatar
 
Posts: 13011
Joined: September 4th, 2003, 1:26 am
Location: Maassluis, The Netherlands

Post Posted October 8th, 2005, 4:03 am

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
nightly build threads 20040225 (FF 0.8.0+) - 20120331 (FF14a)

Peter(6)

User avatar
 
Posts: 13011
Joined: September 4th, 2003, 1:26 am
Location: Maassluis, The Netherlands

Post Posted October 8th, 2005, 4:13 am

@Zeniko
thanks for the quick fix
0.2.2.1 installed w/o a problem
nightly build threads 20040225 (FF 0.8.0+) - 20120331 (FF14a)

old zeniko
 
Posts: 0
Joined: December 31st, 1969, 5:00 pm

Post Posted October 8th, 2005, 4:13 am

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)

User avatar
 
Posts: 13011
Joined: September 4th, 2003, 1:26 am
Location: Maassluis, The Netherlands

Post Posted October 8th, 2005, 4:23 am

I asked Robert_Strong to have a look at this later
nightly build threads 20040225 (FF 0.8.0+) - 20120331 (FF14a)

Mook
 
Posts: 1752
Joined: November 7th, 2002, 9:35 pm

Post Posted October 8th, 2005, 8:58 am

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)
poot.

Philip Chee

User avatar
 
Posts: 6475
Joined: March 1st, 2005, 3:03 pm

Post Posted October 8th, 2005, 9:22 am

zeniko wrote: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
 
Posts: 0
Joined: December 31st, 1969, 5:00 pm

Post Posted October 8th, 2005, 10:15 am

@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.

User avatar
 
Posts: 4399
Joined: April 24th, 2004, 3:04 am
Location: Bay Area, CA

Post Posted October 8th, 2005, 2:04 pm

zeniko wrote: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
 
Posts: 0
Joined: December 31st, 1969, 5:00 pm

Post Posted October 19th, 2005, 1:27 pm

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

User avatar
 
Posts: 223
Joined: November 7th, 2002, 3:49 am
Location: Copenhagen, Denmark

Post Posted October 21st, 2005, 12:49 am

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?
Henrik Gemal
Mozilla Evangelist

Schrade

User avatar
 
Posts: 1187
Joined: March 17th, 2004, 12:24 am

Post Posted October 21st, 2005, 12:52 am

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.
"Linux is for those who hate Windows, BSD is for those who love Unix." -Some Guy
Try my themes: QuBranch and QuTrunk
Fix Firefox's Resized image scrolling speed: <b>Bug 163975</b>

Return to Extension/Theme Releases


Who is online

Users browsing this forum: No registered users and 3 guests