MozillaZine

0.9.1 coming

Discussion of general topics about Mozilla Firefox
shorlander
 
Posts: 183
Joined: November 10th, 2003, 8:28 pm

Post Posted June 25th, 2004, 1:20 pm

mmortal03 wrote:
Hooded One wrote:Wow, Winstripe actually looks like a real theme now. I do agree that the Reload button looks a bit odd... the way the arrows point makes it look less like a circle and more like two paths trying to get out of each other's way. The Update button for the EM has the same problem, except it looks like two paths trying to get out of each other's way and *failing* at it. Heh. Loving the Stop button though.

Also, does the update fix the total retardedness of the Close Tab button?


From what sasquatch said above, I would understand it to still not be fixed. I'll test it myself here in a moment.

Edit: Nope, it is still not fixed.


What exactly is the close-tab button supposed to be doing that it isn't?

prandal
 
Posts: 460
Joined: November 15th, 2002, 4:14 am
Location: Worcester, England

Post Posted June 25th, 2004, 5:48 pm

shorlander wrote:What exactly is the close-tab button supposed to be doing that it isn't?

It's too small. Or, rather, there should be a selectable bit of white space around the icon, as with the navigation buttons. It's virtually impossible to see when it's selected, too. It's only a few lines to fix it, so it shouldn't be too difficult a job.

Hooded One

User avatar
 
Posts: 1591
Joined: February 5th, 2003, 11:42 am
Location: San Francisco, CA

Post Posted June 25th, 2004, 6:07 pm

Yes, the lack of good indication of the hover state is the problem. The padding-less button would be fine if there were enough of a visual difference between the regular and hover state, but there isn't.
Last edited by Hooded One on June 25th, 2004, 6:09 pm, edited 1 time in total.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
SuSE Linux 9.2, Kernel 2.6.8, KDE 3.3.2

James M. Prange
 
Posts: 113
Joined: March 11th, 2004, 1:06 pm

Post Posted June 25th, 2004, 11:29 pm

ehume wrote:Well then, maybe tomorrow.

In the interim, put this line in user.js:

user_pref("app.version", "0.9.0");

Actually, I've been using:

user_pref("app.version", "0.9");

So far, it's worked with 0.9.0+, and I expect that it will also work with 0.9.1, 0.9.1+, or anything else over 0.9.

Of course, that doesn't guarantee that an extension will actually work with a build newer than it's designed for. Personally, I'd think it would be better for the extension developer to stick with a range that the extension is known to work with.

I think it would be better if the extension manager would warn about an incompatible extension, and allow the user to install it anyway if he so chooses.
Regards,
James

funTomas

User avatar
 
Posts: 104
Joined: April 15th, 2004, 4:34 am
Location: Czechia

Post Posted June 25th, 2004, 11:51 pm

All the bugs listed above are FF related. How about TB, also mentioned? The TB bugs related to non-English speaking countries (profiles couldn't be found) are already fixed, will they be fixed in 0.71? I'd appreciate it!

James M. Prange
 
Posts: 113
Joined: March 11th, 2004, 1:06 pm

Post Posted June 25th, 2004, 11:55 pm

Maybe ask in one of the Thunderbird forums?
Regards,
James

savagecat

User avatar
 
Posts: 33
Joined: June 16th, 2004, 4:12 am

Post Posted June 26th, 2004, 3:47 am

0.9.1

YEAH! It can't get here fast enough.

Sailfish
 
Posts: 5681
Joined: November 5th, 2002, 4:58 pm

Post Posted June 27th, 2004, 2:18 am

Steffen wrote:I have to disagree. One of the reasons for the new extension management was the problem that the compatibility of the extension with future app releases is unknown:
Extensions incompatible between application versions break the application - when you upgrade from Application vN to Application vN+1, code changes in the application can cause extensions to stop working, however the extensions are still loaded despite unknown compatibility.
...
Goals: ... To prevent outdated extensions from breaking the application.
http://www.bengoodger.com/software/mb/extensions/extensions.html

I think this needs work because:
  1. In most cases, nothing will have changed between a x.y.0 and an x.y.Z version (this is especially true with themes.)
  2. Requiring extension and theme designers to create new builds every time a version changes, even when no code change is needed is wasteful of their time and resources.
  3. Requiring a user to update an extension/theme for the same reason is wasteful of their time and resources.
  4. Requiring a download from the internet for the same reason is wasteful of its bandwidth.
Perhaps a better solution would be for EM/TM to automatically highlight all extensions/themes orange (or some other "cautionary" indicator) when a version changes. Each one would remain that way until the extension/theme author set some "VERIFIED on x.y.Z" semifore flag as pointed to by the EM:update URL (via some attribute?). Alternately, the user should also be able to override the caution. This would not normally happen; however, in the event that extension/theme author doesn't respond with a VERIFY after a long period of time, the user may decide on their own that it now works.

The above can easily be improved on, I'm sure, but the essence of what I'm suggesting is that an alternative method is needed rather than the existing one, imo.

raananb
 
Posts: 579
Joined: July 21st, 2003, 9:44 pm
Location: Boulogne, France

Post Posted June 27th, 2004, 3:57 am

Sailfish wrote:
Steffen wrote:I have to disagree. One of the reasons for the new extension management was the problem that the compatibility of the extension with future app releases is unknown:
Extensions incompatible between application versions break the application - when you upgrade from Application vN to Application vN+1, code changes in the application can cause extensions to stop working, however the extensions are still loaded despite unknown compatibility.
...
Goals: ... To prevent outdated extensions from breaking the application.
http://www.bengoodger.com/software/mb/extensions/extensions.html

I think this needs work because:
  1. In most cases, nothing will have changed between a x.y.0 and an x.y.Z version (this is especially true with themes.)
  2. Requiring extension and theme designers to create new builds every time a version changes, even when no code change is needed is wasteful of their time and resources.
  3. Requiring a user to update an extension/theme for the same reason is wasteful of their time and resources.
  4. Requiring a download from the internet for the same reason is wasteful of its bandwidth.
Perhaps a better solution would be for EM/TM to automatically highlight all extensions/themes orange (or some other "cautionary" indicator) when a version changes. Each one would remain that way until the extension/theme author set some "VERIFIED on x.y.Z" semifore flag as pointed to by the EM:update URL (via some attribute?). Alternately, the user should also be able to override the caution. This would not normally happen; however, in the event that extension/theme author doesn't respond with a VERIFY after a long period of time, the user may decide on their own that it now works.

The above can easily be improved on, I'm sure, but the essence of what I'm suggesting is that an alternative method is needed rather than the existing one, imo.
It is up to the guy who changes code to verify if the change affects other pieces of code.

If a new version of FF or TB is released, it should be up to the Quality Assurance of Mozilla to test the extensions which worked in the previous release, mark those which became incompatible as incompatible in the extension list and signal them to their developers.

raananb
 
Posts: 579
Joined: July 21st, 2003, 9:44 pm
Location: Boulogne, France

Post Posted June 27th, 2004, 4:03 am

Sailfish wrote:
Steffen wrote:I have to disagree. One of the reasons for the new extension management was the problem that the compatibility of the extension with future app releases is unknown:
Extensions incompatible between application versions break the application - when you upgrade from Application vN to Application vN+1, code changes in the application can cause extensions to stop working, however the extensions are still loaded despite unknown compatibility.
...
Goals: ... To prevent outdated extensions from breaking the application.
http://www.bengoodger.com/software/mb/extensions/extensions.html

I think this needs work because:
  1. In most cases, nothing will have changed between a x.y.0 and an x.y.Z version (this is especially true with themes.)
  2. Requiring extension and theme designers to create new builds every time a version changes, even when no code change is needed is wasteful of their time and resources.
  3. Requiring a user to update an extension/theme for the same reason is wasteful of their time and resources.
  4. Requiring a download from the internet for the same reason is wasteful of its bandwidth.
Perhaps a better solution would be for EM/TM to automatically highlight all extensions/themes orange (or some other "cautionary" indicator) when a version changes. Each one would remain that way until the extension/theme author set some "VERIFIED on x.y.Z" semifore flag as pointed to by the EM:update URL (via some attribute?). Alternately, the user should also be able to override the caution. This would not normally happen; however, in the event that extension/theme author doesn't respond with a VERIFY after a long period of time, the user may decide on their own that it now works.

The above can easily be improved on, I'm sure, but the essence of what I'm suggesting is that an alternative method is needed rather than the existing one, imo.
The person who changes code should measure the impact of the change on other pieces of code.

When a new version of FF or TB is released, it is up to QA of Mozilla to test the compatibility of the extensions which worked with the previous version.

Extensions which became incompatible should be flagged on the extensions list and signalled by QA to their developers.

Thumper's Evil Twin

User avatar
 
Posts: 6422
Joined: December 9th, 2003, 3:52 pm
Location: Glasgow, Scotland

Post Posted June 27th, 2004, 4:04 am

raananb wrote:If a new version of FF or TB is released, it should be up to the Quality Assurance of Mozilla to test the extensions which worked in the previous release, mark those which became incompatible as incompatible in the extension list and signal them to their developers.


Welcome to the world of open source. QA testing is considerably more expedient if performed by El Community.

- Chris

raananb
 
Posts: 579
Joined: July 21st, 2003, 9:44 pm
Location: Boulogne, France

Post Posted June 27th, 2004, 4:04 am

Double post due to server error. Sorry.

Sailfish
 
Posts: 5681
Joined: November 5th, 2002, 4:58 pm

Post Posted June 27th, 2004, 11:22 am

raananb wrote:It is up to the guy who changes code to verify if the change affects other pieces of code.

If a new version of FF or TB is released, it should be up to the Quality Assurance of Mozilla to test the extensions which worked in the previous release, mark those which became incompatible as incompatible in the extension list and signal them to their developers.

Mozilla.org doesn't have the resources nor wherewithall to check all the extensions/themes with each new version, even if it was limited to just the more popular ones.

Given that, it's terribly wasteful to create a system which requires one to redownload their entire extension/theme add-ons even when no code change was needed.

My guess is that because of all the trouble from this, extension/theme designers will just set their maxAppVersion to the next major version and wait for the Community to inform them of breakage. I've already read in this thread where some users are overriding the version number via a user pref in order to get around it.

In its current state, this is a major design flaw and warrants a "blocker" bug until it's remedied, imo.

Sailfish
 
Posts: 5681
Joined: November 5th, 2002, 4:58 pm

Post Posted June 27th, 2004, 12:00 pm

Thumper wrote:Welcome to the world of open source. QA testing is considerably more expedient if performed by El Community.

"Expedient QA testing" almost qualifies as an oxymoron, imo.

capandjudy
 
Posts: 179
Joined: December 23rd, 2002, 9:39 am
Location: Huntington, WV

Post Posted June 27th, 2004, 12:59 pm

polidobj wrote:Will the update feature in 0.9 allow us to ugrade to 0.9.1?


Usually just to be safe with point releases I uninstall the previous version of Firefox or Mozilla for that matter. In the case of Firefox I also delete the profile. Do you think that Firefox 0.9.1 can be installed over 0.9? (both program and profile)? It seems like a basic question but I would rather not run into problems.
Norman Hunter

Return to Firefox General


Who is online

Users browsing this forum: No registered users and 5 guests