First test of Beta 4

[MikeGale]

My first test of Beta 4 was a page I was viewing while evaluating a "web 2" application called Backboard. (This was a manual test, not batch.)

The page was www.seedwatcher.com.

The request showed a 301 to a sixapart blog.

When I tried to see links I had problems.

1) I got a message about more than 500 links, "so I'll only show the bad ones".

2) I accepted it which gave an exception and crash. The exception report should be with you.

[Albert Wiersch]

Thanks Mike. I see the bug report but I'm not sure what is causing this. Can you reproduce this consistently? I assume you used the "Open from the Web" function and not the integrated web browser?

[MikeGale]

Hi Albert,

The first time I ran this was the start after upgrade to Beta 4. I only ran it once.

I've just run it twice again.

Both times I fired up, grabbed the link in the MRU list, validated, then went to links. Looked then exit CSE.

First time 500 links message while I went in. No issues noticed.

Second time when the 500 links message came up I ticked "don't show this again" and same as 1.

On the second occasion the links list was considerably smaller. On exit I got a send error message. I sent, so you should get it. This time the address was a real number not 000000 as in the first case.

(NOTE: I don't know whether the page really has 500 links on it, I haven't checked.)

[Albert Wiersch]

Thanks Mike. I got the second issue (shutdown crash) and I think I have addressed it, but I am still not sure what happened with the first crash. Can you repeat the same type of crash?

[MikeGale]

In my mind the cause of the first crash may well have been that it was the first run after install. (Direct follow through from install dialog.)

If that's the case it won't happen again.

One interesting thing is that it's not reproducible in the normal way. Barring that first run I've had two very different experiences on what looks like the same test. (In other words it looks like an intermittent fault which is a real curse to troubleshoot/diagnose. But you seem to have done that, which is great.)

I'll run some more tests using the Batch wizard.

[MikeGale]

I've run a few batch tests. (A few hundred pages and over a thousand links.)

No issues noticed.

While archiving the reports I did note one thing. When a new report is generated the previous report pages are not deleted. This could lead to several generations of reports in that directory.

For example: Initial test a year ago, had a hundred pages erroring in some way (= 101 report pages), this is fixed and goes down to 5 pages, then one page (the base page). Recent tests have say 3 pages with link issues. So a user going to the source reports gets hit with 101 report pages of which only 4 are current. (A user might get worried!)

It might be worth deleting the previous generation/s of reports.

I tried that seedwatcher URL again in the UI.

When it got to the redirection to seedwatcher.typepad... nothing came down the wires for about 2 minutes. So I cancelled. This froze both the window that shows download progress and the main CSE window. I couldn't close the progress dialog or get the CSE window focused.

I eventually ended the process (the progress dialog process in fact) which shut down all of CSE.

There's no exception reporter for this one.

I repeated the check (seedwatcher) which seemed to go as expected.

When I looked at the link page, it had a red flash on the tab but was entirely empty of content.

I went away to check the link configuration options both in the options dialog and in help.

When I got back the links tab was populated. (A timing issue I'm sure.) Maybe if the link tab said "In progress" while checks are under way.

[MikeGale]

I've now added some JS Lint tests.

I'm getting anomalous results.

1) A JavaScript file altered to have errors, in the UI, does not gives any errors in the Batch Validator tool.

2) In fact I've not seen any JS Lint warnings all errors reported have been with files which are htm's or vbs's.

3) In the UI when checking JavaScript files, I seem to notice that an error early in the file masks later errors. Fixing the early error then reveals a later one.

In the batch tool I'm selecting Validator with "Errors and Warning" or "JS Lint only" on the first tab and errors and warnings on the third tab. This doesn't change the results.

I know nothing about JS Lint (yet). Am I doing it right?

If I am then something odd is happening, probably more than one thing.

[MikeGale]

I've now tested the batch validator with the revised JSLint configuration. It still fails to show Lint warnings or errors. In this case I also tried the "Normal" setting on the batch options tab 1.

I got another exception in CSE when I validated a js file. This is a file I have never edited and don't use. It comprises a list of constants for DHTML editing. (There is an exception report sent for this.)


The file doesn't look valid to me.

Here's the contents.

Code: Select all

// DHTML Editing Component Constants for JavaScript
// Copyright 1999 Microsoft Corporation.  All rights reserved.
//

//
// Command IDs
//
DECMD_BOLD =                      5000
DECMD_COPY =                      5002
DECMD_CUT =                       5003
DECMD_DELETE =                    5004
DECMD_DELETECELLS =               5005
DECMD_DELETECOLS =                5006
DECMD_DELETEROWS =                5007
DECMD_FINDTEXT =                  5008
DECMD_FONT =                      5009
DECMD_GETBACKCOLOR =              5010
DECMD_GETBLOCKFMT =               5011
DECMD_GETBLOCKFMTNAMES =          5012
DECMD_GETFONTNAME =               5013
DECMD_GETFONTSIZE =               5014
DECMD_GETFORECOLOR =              5015
DECMD_HYPERLINK =                 5016
DECMD_IMAGE =                     5017
DECMD_INDENT =                    5018
DECMD_INSERTCELL =                5019
DECMD_INSERTCOL =                 5020
DECMD_INSERTROW =                 5021
DECMD_INSERTTABLE =               5022
DECMD_ITALIC =                    5023
DECMD_JUSTIFYCENTER =             5024
DECMD_JUSTIFYLEFT =               5025
DECMD_JUSTIFYRIGHT =              5026
DECMD_LOCK_ELEMENT =              5027
DECMD_MAKE_ABSOLUTE =             5028
DECMD_MERGECELLS =                5029
DECMD_ORDERLIST =                 5030
DECMD_OUTDENT =                   5031
DECMD_PASTE =                     5032
DECMD_REDO =                      5033
DECMD_REMOVEFORMAT =              5034
DECMD_SELECTALL =                 5035
DECMD_SEND_BACKWARD =             5036
DECMD_BRING_FORWARD =             5037
DECMD_SEND_BELOW_TEXT =           5038
DECMD_BRING_ABOVE_TEXT =          5039
DECMD_SEND_TO_BACK =              5040
DECMD_BRING_TO_FRONT =            5041
DECMD_SETBACKCOLOR =              5042
DECMD_SETBLOCKFMT =               5043
DECMD_SETFONTNAME =               5044
DECMD_SETFONTSIZE =               5045
DECMD_SETFORECOLOR =              5046
DECMD_SPLITCELL =                 5047
DECMD_UNDERLINE =                 5048
DECMD_UNDO =                      5049
DECMD_UNLINK =                    5050
DECMD_UNORDERLIST =               5051
DECMD_PROPERTIES =                5052

//
// Enums
//

// OLECMDEXECOPT 
OLECMDEXECOPT_DODEFAULT =         0
OLECMDEXECOPT_PROMPTUSER =        1
OLECMDEXECOPT_DONTPROMPTUSER =    2

// DHTMLEDITCMDF
DECMDF_NOTSUPPORTED =             0
DECMDF_DISABLED =                 1
DECMDF_ENABLED =                  3
DECMDF_LATCHED =                  7
DECMDF_NINCHED =                  11

// DHTMLEDITAPPEARANCE
DEAPPEARANCE_FLAT =               0
DEAPPEARANCE_3D =                 1

// OLE_TRISTATE
OLE_TRISTATE_UNCHECKED =          0
OLE_TRISTATE_CHECKED =            1
OLE_TRISTATE_GRAY =               2



[Albert Wiersch]

I've run a few batch tests. (A few hundred pages and over a thousand links.)

No issues noticed.

That's good.

While archiving the reports I did note one thing. When a new report is generated the previous report pages are not deleted. This could lead to several generations of reports in that directory.

OK, I understand. I'll make a note to look into that in a future version. Maybe by just adding an option to delete the old report files.

When it got to the redirection to seedwatcher.typepad... nothing came down the wires for about 2 minutes. So I cancelled. This froze both the window that shows download progress and the main CSE window. I couldn't close the progress dialog or get the CSE window focused.

I think I ran into this same issue when I was testing that link so I am working on it. This is one issue that should definitely be fixed for the release version.

When I got back the links tab was populated. (A timing issue I'm sure.) Maybe if the link tab said "In progress" while checks are under way.

Yes, it seems that a lot of links can really slow down the population of the Links tab. I'll make a note of this to see what can be done when I find some extra time.

[MikeGale]

I experimented with that VBS file that gave a lot of Lint warnings. By embedding some simple directives in there I could eliminate these warnings. Not necessarily a thing you'd do every day, but it's satisfying to know that it does work. Here's what I did:

Code: Select all

'/*jsl:ignoreall*/
'<cseignore>
... body of VBScript
'</cseignore>

PS.

That dhtmled.js file (quoted above) doesn't error out if each assignment is terminated with a semi-colon (;) as it should be in JavaScript. (That's still a bug somewhere but it was induced by some fairly insane code!)

[Albert Wiersch]

I've now tested the batch validator with the revised JSLint configuration. It still fails to show Lint warnings or errors. In this case I also tried the "Normal" setting on the batch options tab 1.

Hi Mike,

Strange, I don't have a problem reproducing JavaScript Lint errors and warnings with the Batch Wizard. Could you tell me how to reproduce this in detail?

I got another exception in CSE when I validated a js file. This is a file I have never edited and don't use. It comprises a list of constants for DHTML editing. (There is an exception report sent for this.)

Thanks. Got this and fixed it.

[MikeGale]

I think I've gotten to the bottom of this.

My UI tests got the js using the file system. My batch tests used http.

I now find that:
1) If I use file links from batch it works.
2) If I use http links from the UI I get a 'Cannot check documents of type "application/x-javascript".' message, when I attempt to validate.

So http access locks out *.js file validation.

I can't find a reference to that message in the help, so I'm not sure how or if I can configure it.

The interesting thing is that I can load the file via http, but not validate it!

The batch report puts the "refused files" in the "No errors or warnings" category which is misleading.

[Albert Wiersch]

I now find that:
1) If I use file links from batch it works.
2) If I use http links from the UI I get a 'Cannot check documents of type "application/x-javascript".' message, when I attempt to validate.

The interesting thing is that I can load the file via http, but not validate it!

The batch report puts the "refused files" in the "No errors or warnings" category which is misleading.

Thanks! I'm pretty sure I know what the issue it. CSE HTML Validator doesn't recognize "application/x-javascript" as JavaScript so it thinks it can't check it. This should be fixed in the next BETA.

By the way, I'm pretty sure it should be "application/javascript" instead.

Perhaps I should add a new "Can't check" section in the Batch Wizard?

[MikeGale]

That type is what came out of the web server. (I think it's used by both Apache and IIS.)

Being a bit ignorant about these things, I looked at a debate on them and it looks like it was a bit of a mess. I don't know the current situation.

The browser (as in type declarations in script tags) and the server are not in synch, neither are different user communities using the same declarations.

Seems that these are common:

Code: Select all

application/x-javascript
text/javascript
text/ecmascript

and these might be too:

Code: Select all

application/javascript
application/ecmascript

Given the history of the language there are several other names that might be used, but hopefully I won't encounter in the real world. These would put the following in the language spot:

Code: Select all

cmm
c-minus-minus (or variations)
livescript
jscript

I wouldn't be surprised if jscript named types are present in the wild.

A "Can't Check" section is a good idea.

[MikeGale]

In the batch tool I notice that when using file links I get the file type icon in the list, but when I use http links I get no icon.

It's worth thinking about picking up the file system defined icon for http based files.