Re: firefox 1.5.0.1 gets really sluggish
Irwin Greenwald
> Twice today, Firefox has gotten so sluggish I had to force it closed.
> I was on Expedia trying to plan a trip and after clicking one of the
> buttons, Firefox slowed down so badly I couldn't use it. Nothing would
> click or open after that within the page.
> Same thing happened just now on Mapquest when I was trying to get
> driving directions. I clicked on one of the buttons ("About these
> results" and clicked on another link and the same thing happened - it
> got really sluggish and eventually had to be forced to close.
> Never saw such behavior with 1.5 or any other version of Firefox. The
> only other programs open at the time are Thunderbird 1.5 and Mailwasher
> 5.0. (plus Pc-cillin, ZoneAlarm, etc.) I've got a Pentium IV 1.6 Ghz,
> with 512 MB Ram, plenty of free hard drive space.
> I have Javascript enabled, java not enabled.
> After I forced Firefox to close and re-opened it, it seemed to work OK.
> Anyone else seen anything like this? Any thoughts/suggestions? Could
> it be something coded on those particular pages?
> Thanks :)
> Barbara
One possibility is Pc-cillin: check to see if it has scheduled full
virus scans during the hours you observed the slow-down.
Irwin
--
Irwin Greenwald - Mozilla Champion
Etiquette - http://www.mozilla.org/community/etiquette.html
About Profiles -
http://users.adelphia.net/~irwingreenwald/About%20Profiles.html
OE Quotefix - http://home.in.tum.de/~jain/software/oe-quotefix/
Thorsten Dorr
> William wrote:
>
>> "Barbara" <junkgr...@hotmail.com> wrote in message
>> news:b9Gdnc9plfA...@mozilla.org...
>
>
>> Yes its the same old memory leak I think, even though they claim to
>> have improved it with 0.1 release..I still have to close FF after
>> awhile..really annoying
>> Bill
>>
>
> I too still have the memory leak after upgrading. If I leave it open
> for any amount of time, with no more then 3-5 tabs, it will start taking
> up in excess of 180mb ram. I have 6 extensions running. I may start
> eliminating them one at a time to see if they are the source of the leak.
Yes, Firefox 1.5.0.1 is taking more memory by time if I only
display a google page.
I think one of this extensions could be responsible for this problem:
- Fasterfox
- Linkpreview
Check if you use one of this.
Thorsten
Barbara
On 2/4/2006 10:39 PM Pacific Time, Irwin Greenwald wrote thusly:
> Barbara wrote:
>> Twice today, Firefox has gotten so sluggish I had to force it closed.
>> I was on Expedia trying to plan a trip and after clicking one of the
>> buttons, Firefox slowed down so badly I couldn't use it. Nothing
>> would click or open after that within the page.
>> Same thing happened just now on Mapquest when I was trying to get
>> driving directions. I clicked on one of the buttons ("About these
>> results" and clicked on another link and the same thing happened - it
>> got really sluggish and eventually had to be forced to close.
>> Never saw such behavior with 1.5 or any other version of Firefox.
>> The only other programs open at the time are Thunderbird 1.5 and
>> Mailwasher 5.0. (plus Pc-cillin, ZoneAlarm, etc.) I've got a Pentium
>> IV 1.6 Ghz, with 512 MB Ram, plenty of free hard drive space.
>> I have Javascript enabled, java not enabled.
>> After I forced Firefox to close and re-opened it, it seemed to work OK.
>> Anyone else seen anything like this? Any thoughts/suggestions?
>> Could it be something coded on those particular pages?
>> Thanks :)
>> Barbara
> One possibility is Pc-cillin: check to see if it has scheduled full
> virus scans during the hours you observed the slow-down.
>
> Irwin
Irwin,
No it's not scanning. When it scans, it has a big box open so it's
clear that is what is happening.
Barbara
PeteK
> Twice today, Firefox has gotten so sluggish I had to force it closed.
> I was on Expedia trying to plan a trip and after clicking one of the
> buttons, Firefox slowed down so badly I couldn't use it. Nothing would
> click or open after that within the page.
> Same thing happened just now on Mapquest when I was trying to get
> driving directions. I clicked on one of the buttons ("About these
> results" and clicked on another link and the same thing happened - it
> got really sluggish and eventually had to be forced to close.
> Never saw such behavior with 1.5 or any other version of Firefox. The
> only other programs open at the time are Thunderbird 1.5 and Mailwasher
> 5.0. (plus Pc-cillin, ZoneAlarm, etc.) I've got a Pentium IV 1.6 Ghz,
> with 512 MB Ram, plenty of free hard drive space.
> I have Javascript enabled, java not enabled.
> After I forced Firefox to close and re-opened it, it seemed to work OK.
> Anyone else seen anything like this? Any thoughts/suggestions? Could
> it be something coded on those particular pages?
> Thanks :)
> Barbara
FYI. Here's a link to the Memory Leak Progress
http://www.squarefree.com/2006/02/04/memory-leak-progress/
They do list some extensions that are known to cause leaks.
Irwin Greenwald
Irwin Greenwald
1.5. I suggest you Add/Remove 1.5 (if it exists and/or 1.5.0.1 (if it
exists, delete the program folder (save plugins), (optionally restart
your computer to get rid of cached junk), and reinstall 1.5.0.1 (restore
plugins) and report back on results.
PeteK
Ron Hunter
> William wrote:
>> "Barbara" <junkgr...@hotmail.com> wrote in message
>> news:b9Gdnc9plfA...@mozilla.org...
>>> I was on Expedia trying to plan a trip and after clicking one of the
>>> buttons, Firefox slowed down so badly I couldn't use it. Nothing
>>> would click or open after that within the page.
>>> Same thing happened just now on Mapquest when I was trying to get
>>> driving directions. I clicked on one of the buttons ("About these
>>> results" and clicked on another link and the same thing happened - it
>>> got really sluggish and eventually had to be forced to close.
>>> Never saw such behavior with 1.5 or any other version of Firefox.
>>> The only other programs open at the time are Thunderbird 1.5 and
>>> Mailwasher 5.0. (plus Pc-cillin, ZoneAlarm, etc.) I've got a Pentium
>>> IV 1.6 Ghz, with 512 MB Ram, plenty of free hard drive space.
>>> I have Javascript enabled, java not enabled.
>>> After I forced Firefox to close and re-opened it, it seemed to work
>>> OK.
>>> Anyone else seen anything like this? Any thoughts/suggestions?
>>> Could it be something coded on those particular pages?
>>> Thanks :)
>>> Barbara
>>
>>
>> have improved it with 0.1 release..I still have to close FF after
>> awhile..really annoying
>> Bill
>>
>
> forced closures.
>
Probably depends on what extensions are using, what websites are
visited, and what is done there. Memory leaks happen. It seems like
some people think that their web browser is intended to run all the
time. I just terminate mine when I am done using it for a while, and
reload later. Seems like a plan for defeating the memory leak problem.
Ron Hunter
> In article <18KdnYdK8_QylHve...@mozilla.org>, pawpawbjg60
> @fuse.net says...
>>
>> No memory leak here with FF 1.5 and FF is used all day without any
>> forced closures.
>>
>>
>>
>
>
> Check how much RAM that Firefox is using via the Task Manager - do it
> just after opening FF for the first time, then after leaving FF running
> for a few hours.
>
> Mine starts out at about 40 Mb (FF with 4 tabs open) and after using it
> all day then leaving it just sit there overnight, it's up to 111 Mb.
> Close and re-open, - back to about 40.
>
> Can't see any reason yours would be different, but maybe you just don't
> notice if you have lots of RAM to spare.....
>
If I let the browser sit overnight, then good old Windows swaps it out
of ram, and it takes longer to 'wake it up' than it normally takes to
just reload it. Seems counterproductive to me, memory leak or no.
Ron Hunter
I can't imagine that Fasterfox would be the problem, since it just makes
settings, once. Linkpreview's name suggests it might be storing link
information, would would eat ram in time, but only when actually doing
something.
Moz Champion (Dan)
> William wrote:
>> "Barbara" <junkgr...@hotmail.com> wrote in message
>> news:b9Gdnc9plfA...@mozilla.org...
>
>> Yes its the same old memory leak I think, even though they claim to
>> have improved it with 0.1 release..I still have to close FF after
>> awhile..really annoying
>> Bill
>>
>
> I too still have the memory leak after upgrading. If I leave it open
> for any amount of time, with no more then 3-5 tabs, it will start taking
> up in excess of 180mb ram. I have 6 extensions running. I may start
> eliminating them one at a time to see if they are the source of the leak.
Thats not a memory leak
The longer the program runs, the more RAM it will use.
See
http://kb.mozillazine.org/Reducing_memory_usage_(Firefox)
for a discussion of how to reduce memory usage
Moz Champion (Dan)
> No don't use any of those. The only ones I use are Flashblock, IE
> View, PopUpAlt and User Agent Switcher.
> Seems like the memory leak might be the culprit since closing and
> reopening seems to resolve what ever was going on. I opened the memory
> manager and could see FF taking lots of memory at times, though it
> dropped back down but wouldn't free up the browser lock up. Never had
> it in 1.5 so it was a surprise to me. I usually have FF open a long time
> without problems.
>
> Barbara
See the following for a discussion of the so-called 'memory leak'
problem, which isnt
http://kb.mozillazine.org/Reducing_memory_usage_(Firefox)
Arne Hamre
> The only crunch comes when you decide to use another program, and it
> requests RAM for its use. Windows will automatically swap the Firefox
> RAM to disk, giving you a performance hit when you go back to Firefox.
>
> For tips on reducing your memory usage with Firefox see
> http://kb.mozillazine.org/Reducing_memory_usage_(Firefox)
From the referenced page: "(There is currently no text in this page)"
--
Arne
user
> Twice today, Firefox has gotten so sluggish I had to force it closed.
> I was on Expedia trying to plan a trip and after clicking one of the
> buttons, Firefox slowed down so badly I couldn't use it. Nothing would
> click or open after that within the page.
> Same thing happened just now on Mapquest when I was trying to get
> driving directions. I clicked on one of the buttons ("About these
> results" and clicked on another link and the same thing happened - it
> got really sluggish and eventually had to be forced to close.
> Never saw such behavior with 1.5 or any other version of Firefox. The
> only other programs open at the time are Thunderbird 1.5 and Mailwasher
> 5.0. (plus Pc-cillin, ZoneAlarm, etc.) I've got a Pentium IV 1.6 Ghz,
> with 512 MB Ram, plenty of free hard drive space.
> I have Javascript enabled, java not enabled.
> After I forced Firefox to close and re-opened it, it seemed to work OK.
> Anyone else seen anything like this? Any thoughts/suggestions? Could
> it be something coded on those particular pages?
> Thanks :)
> Barbara
The same was happening to me. Eventually it would just quit altogether,
so I would be forced to use IE (scary thought), which worked fine. The
problem was with my connection settings. My ISP suggests connecting
through a proxy server, and that was the problem. When I selected
'direct connection to the internet' the problem went away.
gwtc
hey Dan, stop posting those empty links. On that page it says:
"(There is currently no text in this page)"
--
Time for a change
gwtc
> There is, but unfortunately drops the closing bracket from the link 8-)
>
Ahhh, there it is. Didn't [wouldn't] have noticed that. Thanks Herb
Herb
It's TB's fault really, isn't it?
I mean if parentheses are valid URL characters, TB shouldn't drop them,
should it? (Ironically, I dropped the TB from my original reply! :-[ )
Someone has probably filed a bug for this.
--
Herbert Eppel
www.HETranslation.co.uk
Moz Champion (Dan)
Oh isnt that just ducky!
Okay, do this
go to your search button and type in reducing memory usage Firefox
on Google (my search engine of choice) you get a list of sites
the very first one listed is
Reducing memory usage (Firefox) - Mozillazine Knowledge Base
click on that gets you to the page I specified.
All I did was copy the url as displayed by Firefox and pasted it into
the message
Here it is again
http://kb.mozillazine.org/Reducing_memory_usage_(Firefox)
Why it doesnt work when referenced directly (I tried the link in my
message and got the same as you) I have no idea. But the page IS there
if you follow the above directions.
Moz Champion (Dan)
well, thats one issue resolved. Hmmm.
http://kb.mozillazine.org/Reducing_memory_usage_(Firefox)
<http://kb.mozillazine.org/Reducing_memory_usage_(Firefox)>
going to see if that corrects the situation, and then go to bugzilla
»Q«
<news:R5ednT76vLKUgXXe...@mozilla.org>:
> Here it is again
> http://kb.mozillazine.org/Reducing_memory_usage_(Firefox)
>
> Why it doesnt work when referenced directly (I tried the link in my
> message and got the same as you) I have no idea.
Parentheses are delimiters for URLs, so they should not appear
unencoded inside URLS. The same goes for other delimiters, such
as [ ] , < > , and whitespaces. There's a list in one of the RFCs.
For mozillazine articles with special characters in their URLs, instead
of copying from the location bar, use 'copy link location' on the
'Article' link in the sidebar.
(http://kb.mozillazine.org/Reducing_memory_usage_%28Firefox%29)
--
»Q«
Moz Champion (Dan)
Now thats its been brought to my attention I can see the error in the
above post. note how the ending parenthesis is NOT included in the
'link' colouring, causing the error.
Off to bugzilla
»Q«
> reported
> https://bugzilla.mozilla.org/show_bug.cgi?id=326189
Sorry I didn't see this part of the thread in time to explain before a
bug was filed. Tb is doing the right thing -- when trying to parse
plain text as a URL, that parenthesis /should/ be treated as a
delimiter unless it's encoded. The bug should be marked invalid.
--
»Q«
Moz Champion (Dan)
Not arguing, I was unaware of such. Can you point me to a site that
explains such?
»Q«
<news:MrQ9762E876A...@QsFQDN.dyndns.org>:
Note also that the apparent workaround of using < angled brackets >
around the whole thing doesn't do a lot of good. It may work in
Thunderbird itself, but it won't in many clients.
E.g., visit the bug report and notice that the bugzilla software has
not included the closing parenthesis in the hyperlink even when you
used the angled brackets. Its attempt to html-ize the plain text
resulted in this:
<<a href="http://kb.mozillazine.org/Reducing_memory_usage_(Firefox">http:/kkb.mozillazine.org/Reducing_memory_usage_(Firefox</a>)>
--
»Q«
»Q«
> »Q« wrote:
>> Sorry I didn't see this part of the thread in time to explain
>> before a bug was filed. Tb is doing the right thing -- when
>> trying to parse plain text as a URL, that parenthesis /should/ be
>> treated as a delimiter unless it's encoded. The bug should be
>> marked invalid.
>
> Not arguing, I was unaware of such. Can you point me to a site
> that explains such?
I'm afraid I can't give a link to the one I'd like to find; there are
now so many RFCs and drafts about URLs, URIs, &c., that I can't seem to
search through them effectively.
Though it doesn't list parentheses as delimiters, RFC 1738 does make
clear that they are unsafe characters and that "all unsafe characters
must always be encoded within a URL." I think that's as close as I'm
going to be able to get.
<http://www.faqs.org/rfcs/rfc1738.html>, section 2.2
--
»Q«
Herb
If parentheses are delimiters for URLs, wouldn't it be better if they
weren't used in web pages, and especially not in Mozilla web pages (I
mean with Mozilla placing great emphasis on web standards and all that)?
IMHO, unsuspecting users wishing to share a link with others shouldn't
have to use workarounds so that others can follow links without such
hiccups.
--
Herbert Eppel
www.HETranslation.co.uk
Ron Hunter
collect the ending parenthesis. If it isn't going to do the job right,
it shouldn't do the job at all.
Moz Champion (Dan)
From section 2.2
Thus, only alphanumerics, the special characters "$-_.+!*'(),", and
reserved characters used for their reserved purposes may be used
unencoded within a URL.
thats the only mention I can find specifically for () - and it states
they can be used unencoded. They are not listed as 'unsafe' characters
»Q«
<news:t8idnYCSx7v...@mozilla.org>:
If it didn't treat them as delimiters, it would collect them into URLs
when they are being used as delimeters, breaking links like this one:
(http://kb.mozillazine.org/Installation_directory)
--
»Q«
»Q«
>> Parentheses are delimiters for URLs, so they should not appear
>> unencoded inside URLS. The same goes for other delimiters, such
>> as [ ] , < > , and whitespaces. There's a list in one of the
>> RFCs.
>>
>> For mozillazine articles with special characters in their URLs,
>> instead of copying from the location bar, use 'copy link
>> location' on the 'Article' link in the sidebar.
>>
>> (http://kb.mozillazine.org/Reducing_memory_usage_%28Firefox%29)
>
> If parentheses are delimiters for URLs, wouldn't it be better if
> they weren't used in web pages, and especially not in Mozilla web
> pages (I mean with Mozilla placing great emphasis on web standards
> and all that)?
AIUI, using them in paths and filenames is ok (though WinXP won't let
me do it), so mozillazine isn't breaking any standards. But using
paths/filenames with parentheses does require them to be encoded when
anyone wants to give a valid URL link to them.
> IMHO, unsuspecting users wishing to share a link with others
> shouldn't have to use workarounds so that others can follow links
> without such hiccups.
One solution would be for Firefox to encode them in the location bar's
display. This is exactly what Fx does with whitespaces. The line
below is not a valid URL because of the unencoded whitespace, but
pasting the entire line into the location bar will turn it into one by
encoding the space, and anyone who managed to surf to that page could
cut-and-paste the URL without worries.
http://remarqs.net/misc/white.html space.html
--
»Q«
Herb
That's interesting - I wasn't aware that URLs could contain spaces.
However, with regard to the parenthesis issue, the present situation is
unsatisfactory, i.e. either FF should encode them, or TB shouldn't drop
the closing bracket. Would you agree?
--
Herbert Eppel
www.HETranslation.co.uk
»Q«
> »Q« wrote:
>
>> Though it doesn't list parentheses as delimiters, RFC 1738 does
>> make clear that they are unsafe characters and that "all unsafe
>> characters must always be encoded within a URL." I think that's
>> as close as I'm going to be able to get.
>>
>> <http://www.faqs.org/rfcs/rfc1738.html>, section 2.2
>
> From section 2.2
> Thus, only alphanumerics, the special characters
> "$-_.+!*'(),", and reserved characters used for their reserved
> purposes may be used unencoded within a URL.
>
> thats the only mention I can find specifically for () - and it
> states they can be used unencoded. They are not listed as 'unsafe'
> characters
You're right. Sorry, I misread the { curlies } as parentheses.
And I now think there's no RFC which sets parentheses aside as
delimiters for http URLs.
AFAICT, the only spec for http URLs in particular is the RFC for the
http protocol itself[1], and WRT unsafe/reserved characters it
points to what was then the latest general RFC for URIs, 2396. 2396
specifically lists parentheses as /unreserved/ characters.[2] So I
think I was wrong, and it's more-or-less ok to use them in http URLs.
(I say more-or-less, because they are used in practice in plain text as
delimiters of URLS.)
[1] <http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.3>
[2] <http://rfc.net/rfc2396.html#s2.3.>
--
»Q«
»Q«
> However, with regard to the parenthesis issue, the present
> situation is unsatisfactory, i.e. either FF should encode them, or
> TB shouldn't drop the closing bracket. Would you agree?
I really don't know. See my response to Dan, in which I cannot find
any RFC justification for regarding them as delimiters and no
justification for encoding them in the location bar.
OTOH, they are used as delimiters sometimes in practice, so if Tb stops
treating them as delimiters, other plain-text URLs won't be turned into
clickable links the way we'd like.
Probably best to let the bug entry stand, and any devs who want to can
mull it over. Hopefully they understand URLs much better than I do.
:)
--
»Q«
Moz Champion (Dan)
trying an experiment here
http://test.url.no-org/(funny)situation
http://test.url.no-org/(funny(situation
http://test)url.no-org/(funny)situation
http://test)url.no-org/(funny)
if the ) character is defined as a delimiter, then why isnt ( treated
the same?
posting this to see what happens to the above
Moz Champion (Dan)
I find it strange that any instance of ) kills the url link, but ( does not
http://test.url(no-org/(funny(situation
works
but
replacing any of the opening parenthesis with closing parenthesis breaks
the url at that specific point
why is ) treated differently from ( ?
teabag
Just a note . My current reader treats the last ")" as a delimiter if there
is a "(" before the http:, else it treats it as part of the URL.
--
tb
Ron Hunter
rather than stopping at the previous character! The exclamation point
in the previous sentence is also a delimiter, but it must be included to
give the sentence meaning...
Ron Hunter
convenience to the user, not to maintain any standard. If is hardly
convenient if the process doesn't pick up the last character of a valid
(to the internet) URL. Just fix what is probably a minor coding error....
Moz Champion (Dan)
The bug, which my bug was a duplicate of is
https://bugzilla.mozilla.org/show_bug.cgi?id=133016
the discussions therein outline the rationale behind the recognition of
the ) character and its limitations
Interestingly enough, Firefox 1.5 and Thunderbird 1.5 dont treat the )
character equal. firefox will not include it if it is followed by a null
or disallowed character for example, but Thunderbird will not include it
in any case. Discussions are ongoing
Herb
Hi Dan,
thanks for the link to the bug discussion. The issue is obviously
complex, but from user/usability point of view it is pretty clear that
the current situation (i.e. TB ignoring valid end brackets) is
unsatisfactory.
Thanks for persisting with it. I just voted for it.
--
Herbert Eppel
www.HETranslation.co.uk
»Q«
> The bug, which my bug was a duplicate of is
> https://bugzilla.mozilla.org/show_bug.cgi?id=133016
>
> the discussions therein outline the rationale behind the
> recognition of the ) character and its limitations
Thanks for posting that link, Dan. After reading all the comments,
ISTM the best solution would be to treat ) as a delimiter if there is
an opening ( at the start of the URL but otherwise include the ) in the
hyperlink. My thinking is that anyone (mis)using parentheses as
delimiters will use them in pairs.
> Interestingly enough, Firefox 1.5 and Thunderbird 1.5 dont treat
> the ) character equal. firefox will not include it if it is
> followed by a null or disallowed character for example, but
> Thunderbird will not include it in any case. Discussions are
> ongoing
I'm lost here. Without an extension, I didn't think Firefox would
attempt to turn plain text into clickable links at all.
--
»Q«
Moz Champion (Dan)
The rationale behind the not rendering doesnt make sense to me. You are
rendering a valid character (according to RFC) as invalid because
someone MIGHT use it incorrectly. Standards compliance means following
the standards, and the standard says that ) is a valid character in a
link. One of the faults of IE is that it allows for poor coding by
fudging results, just like Mozilla is doing in this case.
http://kb.mozillazine.org/Reducing_Memory_Usage_(Firefox)
is a VALID and STANDARDS COMPLIANT link, yet neither Firefox nor
Thunderbird will render it as one.
Firefox does render links. Read the bug itself and note how the examples
I use (which really arent links) are represented as links when reading
it. And note how in Firefox http://test)test.no-org will ALL be a link
whereas here in Thunderbird it appears to be broken after the )
»Q«
> »Q« wrote:
>> "Moz Champion (Dan)" <moz.ch...@sympatico.ca> wrote in
>> <news:rZ-dnRusAf1nc3fe...@mozilla.org>:
>>> Interestingly enough, Firefox 1.5 and Thunderbird 1.5 dont treat
>>> the ) character equal. firefox will not include it if it is
>>> followed by a null or disallowed character for example, but
>>> Thunderbird will not include it in any case. Discussions are
>>> ongoing
>>
>> I'm lost here. Without an extension, I didn't think Firefox
>> would attempt to turn plain text into clickable links at all.
[snip]
> Firefox does render links. Read the bug itself and note how the
> examples I use (which really arent links) are represented as links
> when reading it.
That has nothing to do with Firefox turning plain text into
hyperlinks. The software in the bugzilla system that takes your
input and turns it into html is what is responsible for those links.
Firefox itself is just correctly rendering the html it is served.
Here's a simple example page:
<http://remarqs.net/misc/parentheses.html>
[I've taken the quote below out of order, since it addresses a
different issue]
> Standards compliance means following the standards, and the
> standard says that ) is a valid character in a link. One of the
> faults of IE is that it allows for poor coding by fudging results,
> just like Mozilla is doing in this case.
IMO, standards compliance isn't an issue here. Rather, convenience is.
The URLs we are talking about wrt Thunderbird are /not/ hyperlinks.
They are just plain text. If standards compliance were the goal, they
should just be presented to the user as plain text. But convenience is
the goal; users want plain text turned into hyperlinks so they don't
have to cut-and-paste URLs.
--
»Q«
Moz Champion (Dan)
If convenience is the goal, then the valid standard compliant link such as
http://kb.mozillazine.org/Reduce_Memory_Usage_(Firefox) should be a
clickable link, and it is not, because Thunderbird takes it unto itself
and arbritarily decides it isnt! It isnt convenient whatsoever!
Not only cant I copy/paste a valid link, I cant even TYPE it in! All
because someone else MIGHT use it as a delimiter? This isnt convenience,
it isnt standards compliance, it an arbritary exclusion of a valid
character in a URL, because there is a POSSIBILITY that someone could
mess up a typed in link using it as a delimiter.
This is the SAME attitude that MS has adopted for IE. Regardless of
standards compliance, the program will change things for its own ends.
And once again. I am RESTRICTED from using such links as
http://)test.test.no-org or http://test)test.no-org because Thunderbird
doesnt see the ) as a valid character in urls. It IS a valid character
and should be represented as such.
Ace
expect. FF should NEVER render a link unless the page developer has
specifically it should be. FF should also NEVER guess at what a link
"should" have been just because page developers stuff up. Is is entirely
up to the page developer to ensure their page is HTML compliant and that
each link operates correctly.
TB is a more interesting one, because TB is responsible for both writing
and displaying an HTML email. Unless specifically told about a slightly
unusual url (via Edit/Insert Link), TB is going to have to guess what
the user mean't. Parentheses are not considered "safe" (from what I
understand in the Addressing RFC), but are classed as "extra". In the
normal course of writing a document or email, parentheses would be
considered a delimiter, or punctuation. I believe this is the angle the
rendering within TB should be considered, and seems to be what
occurs......IMHO
Moz Champion (Dan)
> Moz Champion (Dan) wrote:
>> »Q« wrote:
>>> "Moz Champion (Dan)" <moz.ch...@sympatico.ca> wrote in
>>> <news:1-adnWRuVfG...@mozilla.org>:
>>>
>>>> »Q« wrote:
>>>>> "Moz Champion (Dan)" <moz.ch...@sympatico.ca> wrote in
>>>>> <news:rZ-dnRusAf1nc3fe...@mozilla.org>:
>>>
>>
If you are referring to http://www.faqs.org/rfcs/rfc1738.html
unsafe characters are; <,>,",#,%,{,},|,\,^,~,[,],and'
reserved are; ;,/,?,:,@,=,and &
Thus, only alphanumerics, the special characters "$-_.+!*'(),", and
reserved characters used for their reserved purposes may be used
unencoded within a URL
Specifically then, the ) is a valid character in a url, just as $ or
abcde are and can be used unencoded within a URL
the entire idea of someone using one as a delimiter, and TB getting it
wrong hinges on an example such as
http:test.test.no-org being delimited such as
(http:test.test.no-org)
in which, if TB treated ) properly, the link would be incorrect (adding
a trailing ))
So the entire argument with regards to delimiters is in reference to
quoting urls, and some user MIGHT use the character ) as a delimiter.
The / is also used as a delimiter by some (or could be) as in
/http://test.test.no-org/
the above example, using / as a delimiter, results in TB not rendering
any of the text as a url in fact (try it yourself)
) is a valid character in urls, it is not an 'unsafe' character and TB
should render it as such. Just as it does with ( which is another valid
character for urls.
http://test(test.no-org is rendered as a url
http://test)test.no-org is not
and amazingly
<http://test.test.no-org> is rendered as a url INCLUDING the two
'unsafe' < and > delimiters!
in fact the ONLY way to get TB to recognize the ) in a url is to use the
'unsafe' characters < and > to delimit such
<http://test)test.no-org>
which is no surprise, because it also allows you to use the 'unsafe' }
character in a url as well.
Ron Hunter
common sense. No human would make this kind of error, so educate the
computer to work like humans think, rather than trying to rationalize
the computer's shortcomings. Just FIX it.
Ron Hunter
Let's be reasonable. This discussion isn't really about standards, but
about making the rendering a convenience to the user (who doesn't know,
or care, about standards). If an '(' is encountered, then the matching
')' should not be considered a delimiter. Now wasn't that simple?
Herb
Moz Champion (Dan)
> Ace wrote:
>> Moz Champion (Dan) wrote:
>>> »Q« wrote:
>>>> "Moz Champion (Dan)" <moz.ch...@sympatico.ca> wrote in
>>>> <news:1-adnWRuVfG...@mozilla.org>:
>>>>
>>>>> »Q« wrote:
>>>>>> "Moz Champion (Dan)" <moz.ch...@sympatico.ca> wrote in
>>>>>> <news:rZ-dnRusAf1nc3fe...@mozilla.org>:
>>>>
>>>>>>>
>> writing and displaying an HTML email. Unless specifically told about a
>> slightly unusual url (via Edit/Insert Link), TB is going to have to
>> guess what the user mean't. Parentheses are not considered "safe"
>> (from what I understand in the Addressing RFC), but are classed as
>> "extra". In the normal course of writing a document or email,
>> parentheses would be considered a delimiter, or punctuation. I believe
>> this is the angle the rendering within TB should be considered, and
>> seems to be what occurs......IMHO
>
> Let's be reasonable. This discussion isn't really about standards, but
> about making the rendering a convenience to the user (who doesn't know,
> or care, about standards). If an '(' is encountered, then the matching
> ')' should not be considered a delimiter. Now wasn't that simple?
But how 'convenient' is it when a proper and valid URL from a
mozillazine.org site DOESNT work?
http://kb.mozillazine.org/Reducing_Memory_Usage_(Firefox)
or
httP://test)test.no-org (okay I admit thats not a real url, but it
doesnt have ANY invalid, or unsafe characters)
all because some user MIGHT use (http://test/test.no-org) ?
IF a person uses the () as delimiters then the link will be broken (due
to the ADDED ) at the end), but then its simple to explain to the user
that the use of () as delimiters when quoting URLS is incorrect and to
be avoided.
As it is now, when someone quotes a proper and valid URL, it ISNT
rendered correctly, and to fix it, they have to use INVALID characters
(unsafe) to fix it! This is convenience?
Dave Kelsen
This works.
> or
> httP://test)test.no-org (okay I admit thats not a real url, but it
> doesnt have ANY invalid, or unsafe characters)
>
> all because some user MIGHT use (http://test/test.no-org) ?
This works as well.
TB 1.5, FF 1.5.0.1.
RFT!!!
Dave Kelsen
-- Choose your allies carefully; it is unlikely you will be held
accountable for the actions of your enemies.
Herb
Would you care to elaborate?
It doesn't work here, I'm afraid - the point of this discussion is that
if you click on the link in TB, the closing bracket is omitted and you
get a "(There is currently no text in this page)", which come to think
of it merely adds to the confusion, because it seems to suggest that TB
sent you to the correct link (which in this case happens a page with no
text), whereas in fact it didn't!
--
Herbert Eppel
www.HETranslation.co.uk
Moz Champion (Dan)
No,
http://kb.mozillazine.org/Reducing_Memory_Usage_(Firefox)
DOESNT work, it takes you to
http://kb.mozillazine.org/Reducing_Memory_Usage_(Firefox
and there is currently no text on the page
the INTENDED url is
<http://kb.mozillazine.org/Reducing_Memory_Usage_(Firefox)>
see the difference?
In TB 1.5 the http://test)test.no-org
DOESNT work
the link is represented as http://test
whereas it SHOULD be
<http://test)test.no-org>
In TB 1.5 of course (http://test.test.no-org) works! because the final )
is not considered part of the link-
Using ( ) as delimiters in quoting urls such as (http://test.test.no-org)
SHOULDNT work, according to standards the line SHOULD be rendered as
http://test.test.no-org) (note read the preceeding carefully its
suppossed to include the trailing ))
Moz Champion (Dan)
It DOESNT work
http://kb.mozillazine.org/Reducing_Memory_Usage_(Firefox)
as rendered in TB takes you to
http://kb.mozillazine.org/Reducing_Memory_Usage_(Firefox
where there is no text on the site
click on this link
<http://kb.mozillazine.org/Reducing_Memory_Usage_(Firefox)>
to see the difference.
Sorry Dave, you are quite wrong on this one
Dave Kelsen
Quite right. Not knowing what was supposed to be shown, I did in fact
think I went to the correct link. Mea culpa.
RFT!!!
Dave Kelsen
-- I've reached that age in life when I surreptitiously ogle my
co-worker -- a smokin'-hot blonde Russian chick with legs that go on for
days -- and all I can think is, "Man, I wish I could get her to say,
'Boris! Is Moose and Squirrel!'" -- Allen Linds
Herb
No need to apologise - your experience is further proof that the current
situation is unsatisfactory and can be very confusing indeed, especially
in cases such as this where the incorrectly accessed page doesn't show
an error message!
--
Herbert Eppel
www.HETranslation.co.uk