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.
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
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.
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.
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
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
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
Alecf, could you sr this small patch? Thanks!
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
Last Resolved: 16 years ago
Resolution: --- → FIXED
Whiteboard: [ADT2] needs sr → [ADT2] Checked into trunk
Spun off bug 144604 for the local file case.
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+
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
Last Resolved: 16 years ago → 16 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 email@example.com if you care. /be
I sent messages to firstname.lastname@example.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+
The fix has been checked into the mozilla 1.0.0 branch. Still needs ADT approval to get in to the Netscape branch.
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.
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.
You need to log in before you can comment on or make changes to this bug.