Closed Bug 91388 Opened 23 years ago Closed 23 years ago

[RFE] Link checker

Categories

(SeaMonkey :: Composer, enhancement, P4)

enhancement

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.7

People

(Reporter: akkzilla, Assigned: akkzilla)

References

(Blocks 1 open bug)

Details

(Whiteboard: patch attached, awaiting r= and sr=)

Attachments

(1 file, 2 obsolete files)

It would be great to have a link checker which could validate URLs for links, images, js src and other URLs within the document. 4.x had a Java plug-in which did this.
Marking moz 1.0 for feasability study. If it turns out to be hard, it will probably be bumped back. But if it's easy, why not just do it?
Severity: normal → enhancement
Status: NEW → ASSIGNED
Priority: -- → P4
Target Milestone: --- → mozilla1.0
Summary: Want: link checker → [RFE] Link checker
Darin, bbaetz and I worked through the netlib part of this task on Friday and discovered some snags which might need to be fixed on the netlib end. Adding dependencies.
Depends on: 93580, 93581, 93582
I have code that basically works to list the broken URLs, though Darin and I agreed that some of this functionality belongs in netlib (filed bug 87677 on that). Attaching patch. I'd like to get this in as work in progress (still in the debug menu) since a lot of the code (the part that manages the asych calls) will still be needed even after the new netlib API is added. Charley, can you review this? (Again, as work-in-progress, not yet exposed outside the debug menu.) Also, we should discuss what the UI should look like, sometime at your convenience.
Depends on: 97677
Attached patch Patch: some async link checking code (obsolete) (deleted) — Splinter Review
Attached patch Better patch: handles buggy NS server 3.6 (obsolete) (deleted) — Splinter Review
spam composer change
Component: Editor: Core → Editor: Composer
Whiteboard: Partial patch attached, awaiting r= and sr=
Attachment #47755 - Attachment is obsolete: true
Comment on attachment 48507 [details] [diff] [review] Better patch: handles buggy NS server 3.6 r=cmanske
Attachment #48507 - Flags: review+
Blocks: 108296
This broke sometime since it was checked in. I have a fix that makes it work again. Seeking review. Meanwhile, I filed bug 108296 to get some sort of UI for this feature so that we can expose it.
Attached patch small patch: fix regressions (deleted) — Splinter Review
Whiteboard: Partial patch attached, awaiting r= and sr= → patch attached, awaiting r= and sr=
Target Milestone: mozilla1.0 → mozilla0.9.6
Comment on attachment 56351 [details] [diff] [review] small patch: fix regressions sr=kin@netscape.com
Attachment #56351 - Flags: superreview+
Comment on attachment 56351 [details] [diff] [review] small patch: fix regressions r=brade
Attachment #56351 - Flags: review+
Comment on attachment 56351 [details] [diff] [review] small patch: fix regressions r=cmanske
Attachment #48507 - Attachment is obsolete: true
Didn't make the milestone deadline -- flu interfered. Will go in asap.
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Oops, this got forgotten, but it's in now, finally. It sometimes crashes checking e.g. http://www.mozilla.org/nonexistant.html, but I'll file a backend bug on that.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Depends on: 112985
No longer depends on: 112985
how am I supposed to test this ? I saw Check Links in the Debug menu, but that doesn't seem to do anything...I did enter links in a new blank page and was hoping that CHeck Links would do something....I entered valid and invalid URLs.
Charley? The dialog code isn't working -- looks like it regressed again! It's giving: Trying to match attribute 'href' Looking at tag 'A' Exception ERROR in Link checker. e.result=2147746065, gNumLinksToCheck=5 for each link it tries to check. Is this working for you? Obviously, we need to put link checking on our smoketest list, because that's the only way we're going to keep from getting regressed every few weeks.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
debug menu items will not get smoketested... if this is something that is unstable, we should consider taking it out...
It's going to move into the regular menus as soon as we have the dialog working. It's only in debug because we didn't have UI for it before now.
I think we should resolve this bug as fixed, and follow the issue with bug 108296, which is about the UI (which is not complete yet.)
Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
I can verify that's its working by my use of the code
Status: RESOLVED → VERIFIED
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: