Document URL is not passed into W3C HTML Validation tool.

VERIFIED FIXED in mozilla1.0

Status

SeaMonkey
Composer
P3
normal
VERIFIED FIXED
18 years ago
14 years ago

People

(Reporter: rubydoo123, Assigned: Akkana Peck)

Tracking

({regression})

Trunk
mozilla1.0
regression

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [ADT2 rtm] Fixed on trunk)

Attachments

(2 attachments)

(Reporter)

Description

18 years ago
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

18 years ago
setting milestone
Priority: -- → P3
Target Milestone: --- → mozilla1.0

Comment 2

18 years ago
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

18 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

18 years ago
Status: NEW → ASSIGNED

Comment 4

17 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 5

17 years ago
spam composer change
Component: Editor: Core → Editor: Composer

Comment 6

17 years ago
Milestone load balancing.
Target Milestone: mozilla1.0 → mozilla0.9.9

Comment 7

17 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

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

Comment 9

17 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

17 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

17 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

17 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

17 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

Updated

16 years ago
Keywords: nsbeta1 → nsbeta1-
(Assignee)

Comment 14

16 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

16 years ago
Created attachment 79676 [details] [diff] [review]
Patch: fix the http case
(Assignee)

Comment 16

16 years ago
Kathy or Charley, can you review this? 
(Reporter)

Comment 17

16 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

16 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

16 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

16 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

Comment 21

16 years ago
seek reconsideration
Keywords: nsbeta1-
(Assignee)

Comment 22

16 years ago
Alecf, could you sr this small patch?  Thanks!

Updated

16 years ago
Attachment #79676 - Flags: superreview+

Comment 23

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

neat.
sr=alecf
(Assignee)

Comment 24

16 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
Last Resolved: 16 years ago
Keywords: adt1.0.0
Resolution: --- → FIXED
Whiteboard: [ADT2] needs sr → [ADT2] Checked into trunk
(Assignee)

Comment 25

16 years ago
Spun off bug 144604 for the local file case.

Updated

16 years ago
Keywords: nsbeta1 → nsbeta1+

Updated

16 years ago
Whiteboard: [ADT2] Checked into trunk → [ADT2 rtm] Checked into trunk

Comment 26

16 years ago
You didn't use a context diff so a JS strict warning slipped in :-(
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 27

16 years ago
Created attachment 84027 [details] [diff] [review]
Fix strict JS warning

Comment 28

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

r=brade
Attachment #84027 - Flags: review+

Updated

16 years ago
Attachment #84027 - Flags: superreview+
Comment on attachment 84027 [details] [diff] [review]
Fix strict JS warning

sr=jst

Comment 30

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

sr=kin@netscape.com
(Assignee)

Comment 31

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

Comment 32

16 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

16 years ago
Checked (to trunk) the fix for the warning.  Thanks again!
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago16 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
(Assignee)

Comment 35

16 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

16 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

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

a=chofmann,scc,brendan
(Assignee)

Comment 38

16 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
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

16 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

16 years ago
Bug 144604 covers the local file case.

Comment 42

16 years ago
verified on 5/23 branch build.
Keywords: verified1.0.0

Updated

16 years ago
Keywords: adt1.0.0 → adt1.0.0+

Comment 43

16 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.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.