Presentation Screenshots Download Support Development Forum    

Welcome to the Community Forum.

Here you can discuss with other users or with the author, suggest new features, report bugs, ask for filters creation or correction, etc. Select the forum you wish to read or post below :

Forum > Development & Bug report > [Fixed in r122] Update.xhtml SHowing every restart

Pages : [1] 2 3 Add a reply
User info [Fixed in r122] Update.xhtml SHowing every restart
Nov 5 2012, 10:57 pm
Whats happening :
After updating to 1.0.4 (also tried beta) chrome://asf/content/help/update.xhtml this page appears after every restart.

Result expected :
chrome://asf/content/help/update.xhtml should onyl appeared after the update then it should not appear untill next update.
Post #1
Nebular Nerd
Nov 11 2012, 1:32 am
I found a fix which works for me on Nightly 19a.01 x64

Open about:config and then enter extensions.asf into the search bar at the top.

Set to false

and set extensions.asf.version to a high number, I stuck in 25 off the top of my head. Close Firefox fully and reopen, if it worked the pop-up should not appear again. Oddly the extensions.asf.version was empty when I checked again but it does seem to do the trick for me.

***EDIT*** Seems to work the first time to close and reopen but then pops up again on next open. Need to see why it's not holding the version string.
Post #2
Nov 15 2012, 3:02 am
I see the same issue with both release and beta versions in Aurora. Update.xhtml appears whenever a new window is spawned.

This partly breaks GMail, because it happens when you click the little top-right arrow in a reply box to compose the reply in a new window. ASF's update.xhtml appears instead of the reply window. I've had to disable ASF pending a fix.

I'll experiment with Nebular Nerd's fix and see what happens.

Post #3
Nov 15 2012, 11:42 pm
And I did try it, and had Nebular Nerd's experience.

ASF did not pop up on the first invocation of FF after making the about:config changes,. but still overwrote the GMail new window popup. On subsequent invocations of FF, the ASF first time tab was back. :(

Right now I have ASF disabled, and hope for a fix.
Post #4
Nov 25 2012, 11:42 pm
It seems nightly 19a is breaking ASF in different ways :(
I'm still using v17.0 as my everyday browser, so I didn't see that coming.

I didn't expect these bugs. I will have to check and fix them quickly.
They are releasing new versions faster than I'm working on ASF.

I think both reported bugs (gDownloadLastDir undefined and Update/install.xhtml always showing again and again) are both due to the version checker.
They either changed the way the versions are checked against each others, or there's a bug in it.

With beta version, I'm using the SVN revision number, which might be the problem, but you reported that even the official version is broken, so it's probably a bug on Mozilla's side.
But I'll search more informations on this problem and let you know.
Post #5
Nov 28 2012, 9:43 am
I tested ASF on nightly (20.0a1)
It wasn't a problem with the VersionComparator.

So, regarding the two reported bug this month:
- gDownloadLastDir undefined: Fixed (Mozilla introduced a per-window private browsing status).

- Install.xhtml/update.xhtml always re-displayed: I couldn't reproduce this bug.

I will then request more informations from your side to understand what's happening.

? Firefox version:
? ASF version/revision:
(the one displayed in the preferences window's title)
? ASF version stored:
(open about:config, search for asf.version)

Delete the extensions.asf.version value
restart Firefox (or open a new window CTRL+N)
? extensions.asf.version again:

Are you using private browsing by default?
If enabled, nothing can be written in the settings.
Post #6
Nov 28 2012, 9:57 am
As a Mozilla add-ons reviewer and ASF user, I looked into the code and I don't think this is a Firefox bug. Your code is just wrong :) (which is good because it's easier to fix than a bug in Firefox)

The problem is indeed that "extensions.asf.version" is not set. The cause for that is deeper in the code:

In asf_right_click.js, checkASFVersion() you do a XMLHTTPRequest to your locale file to get the current version (sigh!).
That XMLHTTPRequest succeeds but in that function the if clause is never called because "XhrObj.status" is never 0. It is the HTTP return code (which is usually 200 is everything is fine). This let's "this.currentASFVersion" being empty. Later on, in preference_structure_changes() "extensions.asf.version" is set to the empty "this.currentASFVersion".

Sorry, but I have to say this: this function is really bad. You can avoid such bugs by doing it the right way:

* Ship the version in your defaults/preferences/asf.js file. This makes sure there is always a valid version initially but you can still override that pref later in your code.
* Never ever put such information in a locale file! Although it is in your content folder, this makes it just a text file with a unnecessary complex data representation. Even worse, you rely on the version number being in the second line of that file. This is bad practise because it requires a lot of implicit knowledge, very hard for you to remember over time, impossible to know what's going on for others.

If you do that, you can get rid of that synchronous (sigh!) XMLHTTPRequest and the error prone string extraction that comes afterwards.

No hard feelings, I really like your add-on! It helps me a lot while reviewing Mozilla add-ons. Keep up the good work!

If you have questions or need help, just reply here. I'll watch this thread. You can also leave a short message after you uploaded a bugfix version, I'll try to review it asap then.
Post #7
Nov 28 2012, 10:35 am
Thank you a lot for this private review :)

I had to use synchronous mode when Firefox started using asynchronous version checking for add-ons.
my script is dependent on the add-on version number to display part of the GUI, select different settings, etc.
But, since the add-on version switched to Asynch, the result is returned too late.

There are probably a way to do it right, but I didn't find it back when the problem started.
I will try and revert the code back to not use XMLHTTPrequest.

I know that my coding style is nod very good, I'm often tweaking and trying things to find a work around.
I wish I could make it better and properly written (for example not being dependent to the save window, but properly read the active element's link).
I need to rewrite it with database support in mind too.

I have a question, if I may ask here:
edit: moved it to its own thread:

Post #8
Nov 28 2012, 10:52 am
Well, you could use an onLoad eventlistener for the GUI windows in question, read the version number from the preferences service and set it dynamically in your GUI label. That might be a bit of an effort, though. It should also be fine to just stick with the current dtd file (only for display the version number on the GUI!).
Your code logic should use the preferences service to retrieve and store the current version.
Post #9
Nov 29 2012, 10:46 am
Firefox version: 19.0a2 (2012-11-27)
ASF version: 1.0.4
ASF version stored: (blank)
Version stored after restart: (blank)

...and no, I use Chrome for all my private browsing because Firefox doesn't yet support having a non-private window and a private window open at the same time.
Post #10
Pages : [1] 2 3 Add a reply

Return to top