71726 - Document URL is not passed into W3C HTML Validation tool.

Status: VERIFIED FIXED

(SeaMonkey :: Composer, defect, P3)

Description

[rubydoo123]

Under Tools, add an option to access the W3C HTML Validation tool. THe user 
should be able to select the option, have the current document get parsed and 
display the result of the validation in a browser window.

Comment 1

[rubydoo123]

setting milestone

Comment 2

[robinf]

Would choosing this option point users to the page where they can click the link
to the validation tool, or would this option initiate the validation check
directly? Thanks.

Comment 3

[rubydoo123]

we would point to http://validator.w3.org/file-upload.html

but, I would think we would want to get the file address dropped in into the 
text field and initiate the validation so the user would not have to do that 
part. Rather, they would get the result of the validation

Comment 4

[Marcus Pallinger]

It would be great if it could get the current source (the same stuff that view
source uses) and send that through the file validation, which would make it alot
easier to validate dynamic content.

Comment 5

[Syd Logan]

spam composer change

Comment 6

[Charles Manske]

Milestone load balancing.

Comment 7

[Charles Manske]

I've inquired with the W3C Validation newsgroup about feeding the URL for the 
file or remote page to the validator. If that is easy to do, this is a trivial
feature to add and would be of great value.

Comment 8

[rubydoo123]

this is already in the editor : Edit|Validate HTML. Akkana checked this in 
several milestones ago.

Comment 9

[Charles Manske]

I knew it was there, but didn't realize that the command did try to pass the 
URL to the validator -- that doesn't seem to be working now.
Akkana: Do you want to take a look at it?

Comment 10

[Akkana Peck]

It turns out that netlib has stopped calling us back.  We have this JS code:

      var vwin = window.open("http://validator.w3.org/file-upload.html",
                             "EditorValidate");
      // Window loads asynchronously, so pass control to the load listener:
      vwin.addEventListener("load", this.validateFilePageLoaded, false);
or this:
      var vwin2 = window.open("http://validator.w3.org/",
                             "EditorValidate");
      // Window loads asynchronously, so pass control to the load listener:
      vwin2.addEventListener("load", this.validateWebPageLoaded, false);

but in neither the file nor the http case does the callback ever get called (if
I put a dump there, I never see the output).

Cc'ing netlib people: has the api changed?  I don't think this is a race
condition, since it happens even when the url takes a while to load (but there
is a race condition here -- is there any way to get around it?)  Why aren't
these event listeners being called?  This code used to work.

Comment 11

[Darin Fisher]

akk: those aren't necko APIs... i don't know if i can be of much help on this bug.

Comment 12

[Akkana Peck]

Talked to jst about this.  He verifies that it's not reliable to spy on the
document loading in a window from outside the window (not clear what changed or
why it used to work) and suggests using nsIWebProgressListener as wallet does.

Looking at nsWalletService.cpp, it seems that it's registering its
nsIWebProgressListener implementation on the global doc loader service, getting
notifications on everything that's being loaded, getting the url and comparing
to see if it's the one desired.

Surely there's a better way than that.  jst suggested rpotts as someone who also
knows how this mechanism works.

Regardless, it doesn't look like there's much chance of getting the question
answered or understanding why it regressed in time for 0.9.9, so bumping the
milestone.

Comment 13

[Akkana Peck]

Nobody seems to care about this, which means probably no help for getting a fix
for this regression.  Futuring unless someone thinks there's a chance of ADT
approving this.

Comment 14

[Akkana Peck]

Telsa gave me the answer, at least for http urls (which she says she got from
yaneti or shaver): I can pass the complete url into the validator.  It doesn't
give the user a chance to change parameters, but they can always do "Revalidate"
if they want to change something.

I'm checking to see whether there might be a similar solution for file: urls; of
course we can't actually invoke the validator and pass a local file to it
without user confirmation, due to sensible JS security restrictions, but perhaps
there's a url available for "bring up the page with this filename preloaded".

Even if we only solve the http case, though, this would be a big help and IMO
worth pushing into 1.0 (it's very safe and small, won't affect anything outside
validate).

Comment 15

[Akkana Peck]

Attachment: Patch: fix the http case

Comment 16

[Akkana Peck]

Kathy or Charley, can you review this? 

Comment 17

[rubydoo123]

Excellent Akkana! I wonder if we could pull the address of the local file from 
the Location field? The value has to be accessible, well at least it seems it 
should be since it is displayed on the Format|Page Title and Properties dialog - 
of course you can take my assessment with a grain of salt :o)

Comment 18

[Akkana Peck]

Getting the url of the local file is no problem -- we have that.  The problem is
that you can't go to an external url like
http://external.site/page?file=/path/to/local/file.html because if we allowed
that, then pages could put up links that made you upload local files, possibly
without knowing it.

Now, if we could find a url like that which didn't actually upload the file, but
just took a file url for initial value and let the user confirm it, we'd be all
set.  I wonder if there's any chance they have something like that?

Comment 19

[Kathleen :Brade]

Comment on attachment 79676 [details] [diff] [review]
Patch: fix the http case

r=brade (context diff next time, please :-))

Comment 20

[Akkana Peck]

Kin: any chance you could sr this small patch?  Basically, for http validate,
instead of loading the general url and then trying to fill in the url after the
page has come up, we put our page url into the initial validator url.

Comment 21

[Kathleen :Brade]

seek reconsideration

Comment 22

[Akkana Peck]

Alecf, could you sr this small patch?  Thanks!

Comment 23

[Alec Flett]

Comment on attachment 79676 [details] [diff] [review]
Patch: fix the http case

neat.
sr=alecf

Comment 24

[Akkana Peck]

Checked in to the trunk.  I'm going to spin off a new bug for the file url case,
so that this bug can be marked correctly to be considered for the branch.

Comment 25

[Akkana Peck]

Spun off bug 144604 for the local file case.

Comment 26

[[e-mail]]

You didn't use a context diff so a JS strict warning slipped in :-(

Comment 27

[[e-mail]]

Attachment: Fix strict JS warning

Comment 28

[Kathleen :Brade]

Comment on attachment 84027 [details] [diff] [review]
Fix strict JS warning

r=brade

Comment 29

[Johnny Stenback (:jst)]

Comment on attachment 84027 [details] [diff] [review]
Fix strict JS warning

sr=jst

Comment 30

[kinmoz]

Comment on attachment 84027 [details] [diff] [review]
Fix strict JS warning

sr=[e-mail]

Comment 31

[Akkana Peck]

Whoops!  Thanks, Neil.  Do you want to check that in, or should I?

Comment 32

[[e-mail]]

Since I don't have CVS write access I suggest you check it in...
Also I'm not CC'ed to this bug so I didn't know it already had r= and sr=

Comment 33

[Akkana Peck]

Checked (to trunk) the fix for the warning.  Thanks again!

Comment 34

[Brendan Eich [:brendan]]

Does anyone care about this for the 1.0 branch, for release in mozilla1.0?  Time
is very short -- mail [e-mail] if you care.

/be

Comment 35

[Akkana Peck]

I sent messages to [e-mail] requesting approval for this bug and bug
13942 last week, but I guess the messages must have gotten lost.  I just re-sent
both requests.

Comment 36

[Dawn Endico]

Comment on attachment 84027 [details] [diff] [review]
Fix strict JS warning

please check this in on the  1.0 branch by midnight tonight.

Comment 37

[Dawn Endico]

Comment on attachment 84027 [details] [diff] [review]
Fix strict JS warning

a=chofmann,scc,brendan

Comment 38

[Akkana Peck]

The fix has been checked into the mozilla 1.0.0 branch.  Still needs ADT
approval to get in to the Netscape branch.

Comment 39

[Brendan Eich [:brendan]]

What Netscape branch?  If you mean the beta branch, I doubt this merits
inclusion /respinning.  Netscape rtm will branch off of the 1.0 branch later, so
you're all set for rtm if you've checked into the MOZILLA_1_0_BRANCH (note that
branch name is a synonym for MOZILLA_1_0_0_BRANCH).

/be

Comment 40

[sujay]

verified in 5/22 trunk build.

I see Validate HTML under the Tools menu.

The user has to feed in a local file once they reach that W3C validation
page. it is not automatic. requires user intervention.

Comment 41

[Akkana Peck]

Bug 144604 covers the local file case.

Comment 42

[sujay]

verified on 5/23 branch build.

Comment 43

[J. Schreiber]

I have started a new project on http://checky.mozdev.org for validation and
checking web sites against 18 different validation services. Perhaps you are
interested in integration for mozilla or mozilla composer.