Closed Bug 71726 Opened 23 years ago Closed 22 years ago

Document URL is not passed into W3C HTML Validation tool.

Categories

(SeaMonkey :: Composer, defect, P3)

defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.0

People

(Reporter: rubydoo123, Assigned: akkzilla)

Details

(Keywords: regression, Whiteboard: [ADT2 rtm] Fixed on trunk)

Attachments

(2 files)

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.
setting milestone
Priority: -- → P3
Target Milestone: --- → mozilla1.0
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.
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
Status: NEW → ASSIGNED
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.
spam composer change
Component: Editor: Core → Editor: Composer
Milestone load balancing.
Target Milestone: mozilla1.0 → mozilla0.9.9
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.
Keywords: nsbeta1
this is already in the editor : Edit|Validate HTML. Akkana checked this in 
several milestones ago.
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?
Assignee: cmanske → akkana
Status: ASSIGNED → NEW
Summary: Add an option to access W3C HTML Validator → Document URL is not passed into W3C HTML Validation tool.
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.
Keywords: regression
akk: those aren't necko APIs... i don't know if i can be of much help on this bug.
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.
Target Milestone: mozilla0.9.9 → mozilla1.0
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.
Target Milestone: mozilla1.0 → Future
Keywords: nsbeta1nsbeta1-
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).
Status: NEW → ASSIGNED
Keywords: mozilla1.0, nsbeta1
Whiteboard: [ADT2]
Target Milestone: Future → mozilla1.0
Kathy or Charley, can you review this? 
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)
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 on attachment 79676 [details] [diff] [review]
Patch: fix the http case

r=brade (context diff next time, please :-))
Attachment #79676 - Flags: review+
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.
Whiteboard: [ADT2] → [ADT2] needs sr
seek reconsideration
Keywords: nsbeta1-
Alecf, could you sr this small patch?  Thanks!
Attachment #79676 - Flags: superreview+
Comment on attachment 79676 [details] [diff] [review]
Patch: fix the http case

neat.
sr=alecf
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.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Keywords: adt1.0.0
Resolution: --- → FIXED
Whiteboard: [ADT2] needs sr → [ADT2] Checked into trunk
Spun off bug 144604 for the local file case.
Keywords: nsbeta1nsbeta1+
Whiteboard: [ADT2] Checked into trunk → [ADT2 rtm] Checked into trunk
You didn't use a context diff so a JS strict warning slipped in :-(
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment on attachment 84027 [details] [diff] [review]
Fix strict JS warning

r=brade
Attachment #84027 - Flags: review+
Attachment #84027 - Flags: superreview+
Comment on attachment 84027 [details] [diff] [review]
Fix strict JS warning

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

sr=kin@netscape.com
Whoops!  Thanks, Neil.  Do you want to check that in, or should I?
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=
Checked (to trunk) the fix for the warning.  Thanks again!
Status: REOPENED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
Whiteboard: [ADT2 rtm] Checked into trunk → [ADT2 rtm] Fixed on trunk
Does anyone care about this for the 1.0 branch, for release in mozilla1.0?  Time
is very short -- mail drivers@mozilla.org if you care.

/be
I sent messages to drivers@mozilla.org 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 on attachment 84027 [details] [diff] [review]
Fix strict JS warning

please check this in on the  1.0 branch by midnight tonight.
Attachment #84027 - Flags: approval+
Comment on attachment 84027 [details] [diff] [review]
Fix strict JS warning

a=chofmann,scc,brendan
The fix has been checked into the mozilla 1.0.0 branch.  Still needs ADT
approval to get in to the Netscape branch.
Keywords: fixed1.0.0
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
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.
Status: RESOLVED → VERIFIED
Bug 144604 covers the local file case.
verified on 5/23 branch build.
Keywords: verified1.0.0
Keywords: adt1.0.0adt1.0.0+
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.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: