Auto prefix bookmarks with "http://" and "ftp://"

RESOLVED WORKSFORME

Status

SeaMonkey
Bookmarks & History
P3
enhancement
RESOLVED WORKSFORME
18 years ago
2 years ago

People

(Reporter: Henrik Gemal, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
If the user, in the Add Bookmark dialog, enters "www.gemal.dk", mozilla should 
auto prefix the bookmark with: "http://".
The same thing for "ftp.gemal.dk".

Currently the user is just told that this is not a valid URL and the URL dialog 
appears again with the URL deleted!

Build 2000060420

Comment 1

18 years ago
ouch, m18, we should fix this soon.
Target Milestone: --- → M18
(Reporter)

Comment 2

18 years ago
Created attachment 12865 [details] [diff] [review]
Diff to autoinsert www and ftp when creating new bookmarks
(Reporter)

Comment 3

18 years ago
Please review and checkin!
Keywords: patch
OS: Windows 2000 → All
Hardware: PC → All

Comment 4

18 years ago
No, this doesn't fix the problem. It only inserts the protocol if I enter 
www.something or ftp.something, and not if I enter (for example) slashdot.org, 
cnn.com, home.netscape.com, metalab.unc.edu, etc. In effect, it encourages server 
operators to make their domain names unncecessarily long.

Better to explain to the user with a modal dialog that the URL is not valid, and 
why, and return them to the URL field in the Bookmark Properties dialog (which 
has been left open while the error dialog is shown), with the existing text 
intact.

Comment 5

18 years ago
Or you could split the URL field in two and make the first a pop-up menu to
select the protocol (by default to 'http') and the second a text field to enter
the name of the server.
It would look like this (protocol menu expanded) :

Enter a URL for a new bookmark :
           ______       _______________
          | http | :// |               |
          | ftp  |      ???????????????
          |??????|
          |Other?|
           ??????

The 'Other?' item would replace the menu by a text field to enter some unusual
protocol name.

Comment 6

18 years ago
Oups !!!
The '????' means horizontal line except for the one after 'Other' wich means '...'

Comment 7

18 years ago
Why not assume http:// for any URL for which a protocol is not specified.  This
is a WEB browser after all.  This would be my preference.  However, I think the
behaviour should match that of the browser's main URL entry box.  This probably
means assuming http:// for all accept ftp.whatever.org for which ftp:// would be
used.

Comment 8

18 years ago
Reassigning 79 Bookmarks bugs to Ben.  I was told this was going to be done 
shortly about two months ago, but it clearly hasn't been.  I think that's long 
enough for all these bugs to remain assigned to nobody.

Feel free to filter all this spam into the trashcan by looking for this string 
in the message body: ducksgoquack
Assignee: slamm → ben

Comment 9

18 years ago
Why must we complain or assume a protocol at all (by prepending one)?  This 
alert is annoying.  We let the user type "netscape.com" or "www.netscape.com" 
elsewhere, so why not here?  Sounds like a case of overzealous validation...
(Reporter)

Comment 10

18 years ago
I tend to agree with Blake. Should we open a new bug and declare this one 
invalid?

Comment 11

18 years ago
In working w/ bug 64591, bm_props.js (bookmark properties popup) automatically
prepends http:// when no : is found.  I can work around that and enter a
protocol-less bookmark to see what happens (i.e. whether this check is truly
necessary), if anyone would be interested in the outcome.  Either way, both the
new and modify windows should exhibit the same behavior.

Comment 12

18 years ago
I haven't looked at the code but there must be a relevant comment somewhere - the check
was put in to work around another bug by rjc. At this point I can't remember what the trouble
was but bugs crept up when we didn't have the protocol there so rjc created the check to force
people to specify a protocol. There's a verified fixed bug out there somewhere that would explain
all of this.
Off to do some queries...

Comment 13

18 years ago
sweet, got it on the first try; bug 21175 tells the tale.

Comment 14

18 years ago
Thanks for finding that claudius.  Well, neither instance (here or bm-props.js)
of this check is particularly clever (only checking that : exists somewhere in
the url string - not validating the protocol), so we can do one of two things:

- Be slightly clever: prepend http:// to all bookmark url properties w/o a :

- Be more clever: for entries w/o a :, prepend ftp:// to all ftp. addresses,
http:// for anything else. (i.e. just check for ftp. and fall through otherwise)

There may be other prefixes that are interesting here, but if we put this code
into a shared validateBookmarkURL() function or similar, both new and modify
uses could use the same behavior.
Netscape Nav triage team: this is not a Netscape beta stopper. preferable to not 
do input validation here.
Keywords: nsbeta1-
(Reporter)

Updated

18 years ago
Keywords: patch

Updated

18 years ago
Target Milestone: M18 → ---

Comment 16

18 years ago
Should be fixed now; Ben's new dialog isn't as anal.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
(Reporter)

Comment 17

18 years ago
Now the only thing that doesn't quite work is stuff like ftp.gemal.dk
This will give: http://ftp.gemal.dk and not ftp://ftp.gemal.dk

Can we agree that ftp.gemal.dk should result in ftp://ftp.gemal.dk and not 
http://ftp.gemal.dk
?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 18

18 years ago
Marking nsbeta1- bugs as future to get off the radar
Target Milestone: --- → Future
Status: REOPENED → ASSIGNED
Paul Chen is now taking Bookmarks bugs. For your convenience, you can filter 
email notifications caused by this by searching for 'ilikegoats'.

Assignee: ben → pchen
Status: ASSIGNED → NEW

Comment 20

17 years ago
mass reassign of pchen bookmark bugs to ben
Assignee: pchen → ben

Updated

16 years ago
Severity: normal → enhancement
Product: Browser → Seamonkey
Assignee: bugs → nobody
QA Contact: claudius → bookmarks

Comment 21

9 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED

Comment 22

9 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 23

9 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 24

9 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 25

9 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 26

9 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 27

9 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 28

8 years ago
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Last Resolved: 18 years ago8 years ago
Resolution: --- → EXPIRED

Comment 29

8 years ago
The new toolkit bookmark system already does this => WFM.
Resolution: EXPIRED → WORKSFORME
You need to log in before you can comment on or make changes to this bug.