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)
SeaMonkey
Composer
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla1.0
People
(Reporter: rubydoo123, Assigned: akkzilla)
Details
(Keywords: regression, Whiteboard: [ADT2 rtm] Fixed on trunk)
Attachments
(2 files)
934 bytes,
patch
|
Brade
:
review+
alecf
:
superreview+
|
Details | Diff | Splinter Review |
534 bytes,
patch
|
Brade
:
review+
jst
:
superreview+
endico
:
approval+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•23 years ago
|
||
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.
Reporter | ||
Comment 3•23 years ago
|
||
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
Updated•23 years ago
|
Status: NEW → ASSIGNED
Comment 4•23 years ago
|
||
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 7•23 years ago
|
||
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
Reporter | ||
Comment 8•23 years ago
|
||
this is already in the editor : Edit|Validate HTML. Akkana checked this in several milestones ago.
Comment 9•22 years 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.
Assignee | ||
Comment 10•22 years ago
|
||
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
Comment 11•22 years ago
|
||
akk: those aren't necko APIs... i don't know if i can be of much help on this bug.
Assignee | ||
Comment 12•22 years ago
|
||
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
Assignee | ||
Comment 13•22 years ago
|
||
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
Assignee | ||
Comment 14•22 years ago
|
||
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
Assignee | ||
Comment 15•22 years ago
|
||
Assignee | ||
Comment 16•22 years ago
|
||
Kathy or Charley, can you review this?
Reporter | ||
Comment 17•22 years ago
|
||
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)
Assignee | ||
Comment 18•22 years ago
|
||
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•22 years ago
|
||
Comment on attachment 79676 [details] [diff] [review] Patch: fix the http case r=brade (context diff next time, please :-))
Attachment #79676 -
Flags: review+
Assignee | ||
Comment 20•22 years ago
|
||
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
Assignee | ||
Comment 22•22 years ago
|
||
Alecf, could you sr this small patch? Thanks!
Updated•22 years ago
|
Attachment #79676 -
Flags: superreview+
Comment 23•22 years ago
|
||
Comment on attachment 79676 [details] [diff] [review] Patch: fix the http case neat. sr=alecf
Assignee | ||
Comment 24•22 years ago
|
||
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
Assignee | ||
Comment 25•22 years ago
|
||
Spun off bug 144604 for the local file case.
Whiteboard: [ADT2] Checked into trunk → [ADT2 rtm] Checked into trunk
Comment 26•22 years ago
|
||
You didn't use a context diff so a JS strict warning slipped in :-(
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 27•22 years ago
|
||
Comment 28•22 years ago
|
||
Comment on attachment 84027 [details] [diff] [review] Fix strict JS warning r=brade
Attachment #84027 -
Flags: review+
Updated•22 years ago
|
Attachment #84027 -
Flags: superreview+
Comment 29•22 years ago
|
||
Comment on attachment 84027 [details] [diff] [review] Fix strict JS warning sr=jst
Comment 30•22 years ago
|
||
Comment on attachment 84027 [details] [diff] [review] Fix strict JS warning sr=kin@netscape.com
Assignee | ||
Comment 31•22 years ago
|
||
Whoops! Thanks, Neil. Do you want to check that in, or should I?
Comment 32•22 years ago
|
||
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=
Assignee | ||
Comment 33•22 years ago
|
||
Checked (to trunk) the fix for the warning. Thanks again!
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
Whiteboard: [ADT2 rtm] Checked into trunk → [ADT2 rtm] Fixed on trunk
Comment 34•22 years ago
|
||
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
Assignee | ||
Comment 35•22 years ago
|
||
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 36•22 years ago
|
||
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 37•22 years ago
|
||
Comment on attachment 84027 [details] [diff] [review] Fix strict JS warning a=chofmann,scc,brendan
Assignee | ||
Comment 38•22 years ago
|
||
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
Comment 39•22 years ago
|
||
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•22 years ago
|
||
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
Assignee | ||
Comment 41•22 years ago
|
||
Bug 144604 covers the local file case.
Updated•22 years ago
|
Comment 43•22 years ago
|
||
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.
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•