Status

()

P5
minor
20 years ago
2 years ago

People

(Reporter: BenB, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 1 bug, {helpwanted, html5})

Trunk
helpwanted, html5
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta3-][rtm[necko-would-take])

Attachments

(3 attachments)

(Reporter)

Description

20 years ago
Reproduce.
Feed NS_NewURI with wild URLs, like <http://###>, <http://())>, <http:%%%%> or
<mailto:/@/> (w/o anglebrackets).
Actual result:
It reports success.
Expected result:
Failure.
(Reporter)

Updated

20 years ago
Blocks: 19251
(Reporter)

Comment 1

20 years ago
*** Bug 7176 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 2

20 years ago
*** Bug 20079 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 3

20 years ago
Tever, I heard, gagan were on vacation. Can you reassign to someone appropriate?

Updated

20 years ago
Blocks: 13449
Target Milestone: M15

Comment 4

20 years ago
Weird corner cases. Low priority.
(Reporter)

Comment 5

20 years ago
I know, I will be flooded with flames, if " ---@--- " or so is turned into a
mailto link.
(Reporter)

Comment 6

20 years ago
In BETA, that is.
(Reporter)

Comment 7

20 years ago
You're propably right, but it's a MUST for final.

Comment 8

20 years ago
Bulk move of all Necko (to be deleted component) bugs to new Networking

component.

Comment 9

19 years ago
Is now reporting failure in a dialog box for the given urls. What remains is
that it finally gives this box for the www.xxx.com version and not for the
original xxx, which is a dup of bug 23019.
(Reporter)

Comment 10

19 years ago
This bug is not about the browser.

Comment 11

19 years ago
andreas?
Assignee: gagan → andreas.otte
(Reporter)

Comment 12

19 years ago
Assuming "RTM" keyword is for nominating "must be fixed in stable release"-bugs.
Keywords: rtm

Comment 13

19 years ago
One possible solution to this for nsStdURLs could be a matrix much like the
escape-matrix in nsURLHelper which says which chars are valid in each part of an
URI. Violating the matrix could result in an NS_ERROR_MALFORMED_URI error.

SimpleURIs will be more complicated, each uritype will need different rules
integrated into each parser.

Updated

19 years ago
Status: NEW → ASSIGNED

Comment 14

19 years ago
Posted patch First cut ...Splinter Review

Comment 15

19 years ago
The above is a first cut on a solution to this bug following the outline
mentioned above. It currently only works only for detecting invalid chars in
hostnames and it works only for nsStdURL-type URLs. It can be easily extended
for other parts of an URL.

Want to give it a try Ben?

Comment 16

19 years ago

Comment 17

19 years ago
Okay, the above extended patch also handles mailto urls, but it comes down to
what we allow as usernames and/or hostnames/domains.
(Reporter)

Comment 18

19 years ago
Comments about mailto parser in bug #32442 "More checks for mailto URLs".

Comment 19

19 years ago
-> M16
Target Milestone: M15 → M16

Comment 20

19 years ago
Moving to M17 which is now considered part of beta2.
Target Milestone: M16 → M17
(Reporter)

Updated

19 years ago
Depends on: 40047
(Reporter)

Updated

19 years ago
No longer depends on: 40047

Updated

19 years ago
Depends on: 31225

Comment 22

19 years ago
The problem with this bug is that we have to deal hostnames like
http://www.ökobank.nu. Because of different encodings we end up with
http://www.wörterbuch.nu/ or http://www.w%F6rterbuch.nu/ . The last one is okay
and will be accepted by the check-function, the first one is not. If the url is
resolved from a link we get both versions, the last one seems to take effect and
it works (on windows). If I type the url into the urlbar we only get the first
version which is catched by the check-function. Why this difference? CCing Chris
Waterson, who working on something similar before.

See bug 31225 or http://www.nunames.nu/eu-lang-test.htm for a list of problem
urls.

Comment 23

19 years ago
Opps .. the original url was http://www.wörterbuch.nu.

Comment 24

19 years ago
I don't know. What encoding does the URL bar use? If it's the platform encoding
(probably would make the most sense -- allows cut-n'-paste from other apps,
right?) then the URL bar code should probably be using that to encode strings
before dispatching them to necko. I image what's happening right now is that
it's UTF-8 encoding the string.

cc'ing ftang, who probably remembers best what 4.x did. cc'ing ben goodger and
law who are probably the ones that will need to fix this...

Comment 25

19 years ago
I'm not going anywhere here because of bug 31225, moving to M18 for now. 
Keywords: helpwanted
Target Milestone: M17 → M18

Comment 26

19 years ago
back to gagan for reassignment, my time schedule is getting worse, I have to
stop sitting on this bug.
Assignee: andreas.otte → gagan
Status: ASSIGNED → NEW

Updated

19 years ago
Target Milestone: M18 → Future
(Reporter)

Comment 27

19 years ago
We're looking painfully silly, if we "recognize" and link http:%%% or a%%%@%%%
in TXT->HTML (e.g. Mailnews).
If I understood it right, there is a working patch, which just waits for some
very freaky i18n issue to be resolved. Can't we just clarify that, and then
[adjust and] check in the patch, please?
Whiteboard: nsbeta3
Adding nsbeta3 keyword to bugs which already have nsbeta3 status markings so 
the queries don't get all screwed up.
Keywords: nsbeta3

Updated

19 years ago
Whiteboard: nsbeta3 → [nsbeta3-]

Comment 29

19 years ago
per new rules, not critical for rtm
Whiteboard: [nsbeta3-] → [nsbeta3-][rtm-]

Updated

19 years ago
Blocks: 61999

Comment 30

18 years ago
mass move, v2.
qa to me.
QA Contact: tever → benc
(Reporter)

Comment 31

18 years ago
I wonder, why bug 32442 doesn't block this one yet.

Isn't it time to do something for this bug now?
Depends on: 32442
(Reporter)

Updated

18 years ago
Keywords: nsbeta3, nsrtm → mozilla1.0
I see in comment 27, from three years ago, that there was 'almost a patch.'

/Was/ there almost a patch? Is there still one?

Is this bug still a going concern?

Granted, it's minor, but there ought to be some filtering for invalid URLs.

-M
Severity: normal → minor
(Reporter)

Comment 33

16 years ago
I don't think it's minor. Claiming that <http://###> is a valid URI is just
nonsense and has visible effects in the plaintext recognizer.
Severity: minor → normal

Comment 34

16 years ago
gagan shouldn't own this bug...

Some of this sounds related to bug 140379. You guys know the guts better than I
do, but I can justify that bug on more concrete terms
Assignee: gagan → darin

Updated

16 years ago
Severity: normal → minor
Keywords: mozilla1.0
Priority: P3 → --

Updated

13 years ago
Assignee: darin → nobody
QA Contact: benc → networking
Target Milestone: Future → ---
(Reporter)

Updated

8 years ago
Duplicate of this bug: 561586
(Reporter)

Updated

8 years ago
Keywords: html5
Blocks: 561586
How easy would this be to implement?

Since HTML5 spec. has a smaller set of URIs for mailto: than spec, should this target for RFC 3986 and 3987, or HTML5?
Whiteboard: [nsbeta3-][rtm-] → [nsbeta3-][rtm[necko-would-take]
You need to log in before you can comment on or make changes to this bug.