squashed bug cemetery
From Brian: I had this problem too but it seems to have gone away now. I tried changing the skin using the History page but when the page refreshed it still used the old skin. I tried several times but always got the same result. Without restarting POPFile, I moved to another UI page (Admin, I think), tried to change the skin again and it worked first time. Then I checked the other UI pages and the skin changes all worked first time - including the History page. (I used different skins for these tests, instead of just switching back and forth between two skins). Then I shutdown POPFile, restarted it and tried to use the History page to change the skin… and it worked first time.
From Brian: I can easily reproduce the problem by using adduser.exe to create a new User Data folder with just the 4 default buckets. Alternatively, just rename or delete popfile.db and let POPFile create an empty database. After doing this, the History page will fail to change the skin. The cure involves using one or more of the other UI pages to change the skin, once that has been done the History page can be used to change the skin.
I was trying to change skins repeatedly to reproduce the bug above and then noticed that the 'Add history columns' checkboxes were all gone. The form itself, label, apply button and all were still there. Just the checkboxes with their accompanying labels were awol.
Is this with all skins after changing repeatedly or just certain skins? On OSX the background outside Shell is purposely hidden (I think). Since these new config options are outside Shell they get hidden. I don't see this as a skin bug, the Config options should be inside Shell. There obviously should be a seperator between them and the actual useful page content, but not Shell. Up till now most all page elements between the header and footer were inside shell. – Joseph
No, this is not skin-dependent. Once those checkboxes are gone, I can change skins as much as I like, they remain lost.
Loader.pm has a small bug. When the “POPFile v0.23.0 running” message was restored, the associated “flush STDOUT;” line was left out. This means the Message Capture utility will not show this message (and the preceding “Level 5 html” one) until POPFile is shut down (or if an error message is output). Inserting “flush STDOUT;” in Loader pm 1.32 after line 689 (print “\n\nPOPFile ”, $self→{version_string__}, “ Running\n”;) fixes this bug.
If the 'Size' column is displayed, no data appears in it and the console shows lots of errors (Use of uninitialized value in sprintf at C:\PROGRA~1\PMUTESTS/UI/
HTML.pm line 2504). I looked at the 'history' table and found it contains 'size' data. (I'm using a database from 0.22.2 which current CVS upgraded for me)
Odd number of elements in hash assignment at d:/compiler/ActivePerl/site/lib/Crypt/Random.pm line 107.
Use of uninitialized value in division (/) at d:/compiler/ActivePerl/site/lib/Crypt/Random/Provider/rand.pm line 36.
Use of uninitialized value in concatenation (.) or string at c:\pf\run/Classifier/Bayes.pm line 1500. (CVS v1.341)
Use of uninitialized value in concatenation (.) or string at c:\pf\run/UI/HTML.pm line 1842. (CVS v1.340)
Use of uninitialized value in hash element at c:\pf\run/Classifier/Bayes.pm line 1498. (CVS v1.341)
Use of uninitialized value in hash element at c:\pf\run/Classifier/Bayes.pm line 1504. (CVS v1.341)
Use of uninitialized value in hash element at c:\pf\run/Classifier/Bayes.pm line 3276. (CVS v1.341)
Use of uninitialized value in hash element at c:\pf\run/Classifier/Bayes.pm line 3277. (CVS v1.341)
Use of uninitialized value in hash element at c:\pf\run/Classifier/Bayes.pm line 3278. (CVS v1.341)
Use of uninitialized value in hash element at c:\pf\run/UI/HTML.pm line 1026. (CVS v1.340)
Use of uninitialized value in hash element at c:\pf\run/UI/HTML.pm line 1051. (CVS v1.340)
Use of uninitialized value in numeric gt (>) at c:\pf\run/UI/HTML.pm line 1851. (CVS v1.340)
Use of uninitialized value in numeric gt (>) at c:\pf\run/UI/HTML.pm line 1856. (CVS v1.340)
Calls to
HTML::load_template__() now need a $page parameter. This isn't given in many places.
“Jump to page x” does not check the supplied page number properly - with 20 msgs per page and 79 msgs in my history, entering “5” displays the last page (page 4) as expected but if I enter a larger number (e.g. 10) it uses “?start_message=180” and thus shows an empty page. Repeatedly clicking the “<Previous” link will eventually display msgs 61-79.
The Javascript code in password-page.thtml doesn't work in any of my browsers. It is supposed to give focus to the username input field (which is a good thing), but I guess we'd need an onLoad event handler for this to work. We'd have to get our hands on the body element, though, which isn't possible changing only password-page.thtml. Should we change common-middle.thtml and set a default onLoad handler there that the other templates might overwrite at will? Is this even possible?
For me it is working on Firefox, Opera, and
IE. On FF it works all the time (page load and reload). On
IE and Opera it only works on the inital page load (reload doesn't do it). On older Mozilla (1.7?) based K-Meleon it doesn't work at all (don't know if that is a Moz or KM problem). Not being able to access the body element is a problem. I don't really like the idea of a default onLoad handler, but this isn't the only page that uses JS. The history page has some too, that for some reason seems to work better. I have done some work on confirm dialogs for certain buttons, such as Remove All, maybe Remove Page, Reset Stats, Reset Bucket. So it could be useful. But how this would be implemented I am not sure. I guess the body tag would just automatically call the default function which could then include other template files with the JS. But JS normally is in the head of the
HTML. It seems to work outside, but is it proper? If it should be in the head we are back to the same problem, though from the amount of code I see outside of head I think its ok. Using onLoad likely would make the focus work all the time in
IE and Opera.
Any idea why this is working for you and not at all for me? Strange. If was thinking about something like <body onLoad=“
OnLoadHandler”>. The default function named
OnLoadHandler would simply do nothing. But later on, you should be able to define a second function Foo and simply say
OnLoadHandler = Foo and voila.
here is an example.
I just checked in something based on your suggestion. Apparently we don't need
OnLoadHandler = Foo, just define a function with the original name. If we have trouble with that I will go back to your way, but this one seems to work everywhere I tested (except the K-Meleon based on Moz 1.7 but the renaming method didn't work on KM either). This should add tons of flexability.
Works in all my browsers (Mozilla, Firefox,
IE, Opera). I think we can soon remove this 'thread' from this page.
After getting everything installed I can still not get PF to run:
"makerandom" is not exported by the Crypt::Random module
<code>"makerandom_itv" is not exported by the Crypt::Random module
"makerandom_octet" is not exported by the Crypt::Random module
Can't continue after import errors at j:/Perl/site/lib/Crypt/Random/Generator.pm line 12
BEGIN failed–compilation aborted at j:/Perl/site/lib/Crypt/Random/Generator.pm line 12.
Compilation failed in require at j:/Perl/site/lib/Crypt/Random.pm line 18.
BEGIN failed–compilation aborted at j:/Perl/site/lib/Crypt/Random.pm line 18.
Compilation failed in require at J:\popfil~1\run/Classifier/Bayes.pm line 44.
BEGIN failed–compilation aborted at J:\popfil~1\run/Classifier/Bayes.pm line 44.
Compilation failed in require at J:\popfil~1\run/POPFile/Loader.pm line 456.
</code>
This error is connected with the way in which POPFile uses the packing list (in popfile.pl). A temporary fix is to rename (or delete) the popfile.pck file from the main program folder. The
BerkeleyDB check appears to cause this problem.
I saw the posts about that, didn't realize it caused this kind of error. Nothing in the error seem to be related to
BerkleyDB. That is really odd. But would explain why I could get this to work on my other computer, it never had
BerkleyDB installed.
Right. It is really odd and it will work when
BerkeleyDB is not installed.
Current CVS works with Crypt::CBC v2.12 but does not work with the latest version (2.14). With v2.14 POPFile crashes with the following console error message when you try to access the UI: “Cipher stream did not contain IV or salt, and you did not specify these values in new() at C:\PROGRAM FILES\023-TEST/UI/HTTP.pm line 275”
jac: On Buckets tab with blue skin, first bucket's buttons are larger. May be a
CSS parsing error, I can't see why its doing it. I didn't notice it on any other skin.
jac: was a FF
CSS parsing error. Found a work around.
jac: There may be something wrong with the layout of the bucket page from a screen reader point of view. I think screen readers would see things pretty much like Lynx does and it doesn't look good on the buckets page. See the
history page and then see the
buckets page in these screenshots from Lynx.
jac: The “Changed to ___” message does not colspan properly when the first message on the page is reclassified, that one gets
colspan=“”.
Example
jgc: This isn't exactly a new problem, but I only noticed it now: If we send a 404 error, we only send the error code, but not a 404 page. It might be that we don't really need one (if the UI works without errors), but should we have one?
jgc: When using the history page to change the language, the date format in the footer is not updated when the page is automatically refreshed (but the rest of the page shows the new date format in the 'Arrived' and 'Date' columns and their tooltips). A manual refresh is required to get the footer to use the correct date format (the browser's 'refresh' button or the history page's 'refresh' link or selecting a different UI page)
Template Strict problems in UI/
HTML.pm
jgc: If you enter a login with incorrect password it goes back to PW entry page. Then enter the correct password and you end up stuck at a blank page
http://localhost:8080/password . Part of the problem seems to be the password page is just totally blank when logged in, it should redirect to history just in case a user gets there somehow. In this case the other problem is that the password page directs you to the intended
URL when you login, since the incorrect login takes you to /password that is now the destination you go to when finally logged in.
jgc: POPFile 0.22.2 ships with a minimal Perl based upon
ActivePerl 5.8.4 but this is no longer compatible with the optional SSL components in the University of Winnipeg repository (they require a newer version of Perl).
ActivePerl 5.8.7 Build 813 was released 7 June 2005.
When there are no magnets we shouldn't have the Update and Remove buttons on the Magnets config. In fact, we don't need the section that lists current magents at all if there aren't any, we could just start the page with the Create New Magnet section. We should also replace the two buttons with our new Apply Changes button to make the interface consistant with Buckets page.