RT breaks *very* long URL's

Hello,

at first i want to emphasize that this project is
really great … thanks to all those people developing it :slight_smile:

Actually we are using version 2.0.11 here and everything
works very, very fine. So far, so good.

While playing around during the implementation process i
figured out a kind of ‘optical’ bug in ShowTransaction -
at least … i think that the reasonable code is located
there (i am still going through the whole code).

This optical misbehaviour is easy to reproduce.

feel free to download a screenshot from my /pub:

ftp://amazone.boerde.de/pub/RT2/rt-devel.jpg

or simply create a ticket (either via mailgateway) or
by hand in your own RT.

As long as the URL’s length is =< 72 characters (including
the http:// part of it ofcourse) there’s no problem
from the ‘ShowTransaction’ code displaying it properly… but
as soon as it gets longer than 72 characters the substitution
in ‘ShowTransaction’ in line 43 doesn’t work as expected.
The URL gets broken there, because the tag will be
closed after these 72 characters…

[ShowTransaction located in /rt2/WebRT/html/Ticket/Elements]

I tried several things to have a workaround for it. In special
i removed line 43 completely … forcing my staff-members to
cut/paste the URL manually. But i think that there must be a better
solution to get around this ‘optical misbehaviour’.
So I also played with the

 tag in lines 55-57 … but the
solution wasn’t acceptable at all - since it looked quite ugly then -
at least it worked as expected then…

So my question to the devel-list is if,

Am I the first one recognizing this - erm - 'bug' ? (i won't call
call it a 'bug' at all - since it only affects very long URL's)
or is this just mentioned somewhere (digging in the mailinglist
didn't gave me some hints on this) ?

Friendly regards,

Frank Reppin

Heidestr. 15
39112 Magdeburg

Interesting. Text::Wrapper isn’t supposed to break words that don’t
fit on one line. The best place to play around with this is
WebRT/html/Ticket/Elements/ShowTransaction. you might want to try
switching the order of the URL escaping and the text wrapping.
If that works, I’ll happily make the switch in my sources.

-jOn Thu, Feb 14, 2002 at 06:05:44PM +0100, Frank Reppin wrote:

Hello,

at first i want to emphasize that this project is
really great … thanks to all those people developing it :slight_smile:

Actually we are using version 2.0.11 here and everything
works very, very fine. So far, so good.

While playing around during the implementation process i
figured out a kind of ‘optical’ bug in ShowTransaction -
at least … i think that the reasonable code is located
there (i am still going through the whole code).

This optical misbehaviour is easy to reproduce.

feel free to download a screenshot from my /pub:

ftp://amazone.boerde.de/pub/RT2/rt-devel.jpg

or simply create a ticket (either via mailgateway) or
by hand in your own RT.

As long as the URL’s length is =< 72 characters (including
the http:// part of it ofcourse) there’s no problem
from the ‘ShowTransaction’ code displaying it properly… but
as soon as it gets longer than 72 characters the substitution
in ‘ShowTransaction’ in line 43 doesn’t work as expected.
The URL gets broken there, because the tag will be
closed after these 72 characters…

[ShowTransaction located in /rt2/WebRT/html/Ticket/Elements]

I tried several things to have a workaround for it. In special
i removed line 43 completely … forcing my staff-members to
cut/paste the URL manually. But i think that there must be a better
solution to get around this ‘optical misbehaviour’.
So I also played with the

 tag in lines 55-57 … but the
solution wasn’t acceptable at all - since it looked quite ugly then -
at least it worked as expected then…

So my question to the devel-list is if,

Am I the first one recognizing this - erm - ‘bug’ ? (i won’t call
call it a ‘bug’ at all - since it only affects very long URL’s)
or is this just mentioned somewhere (digging in the mailinglist
didn’t gave me some hints on this) ?

Friendly regards,

Frank Reppin


Heidestr. 15
39112 Magdeburg


rt-devel mailing list
rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel

http://www.bestpractical.com/products/rt – Trouble Ticketing. Free.

Interesting. Text::Wrapper isn’t supposed to break words that don’t
fit on one line. The best place to play around with this is
WebRT/html/Ticket/Elements/ShowTransaction. you might want to try
switching the order of the URL escaping and the text wrapping.
If that works, I’ll happily make the switch in my sources.

-j

Hi,

another - maybe much more useful point to change this behaviour
seems to be in (leaving /rt2/WebRT/html/Ticket/Elements/ShowTransaction
untouched)

/rt2/WebRT/html/Elements/MessageBox

i made a simple change there …

cruncher# diff MessageBox MessageBox.ORIGINAL
1c1
< <TEXTAREA COLS=<%$Width%> ROWS=15 WRAP=SOFT NAME=“<%$Name%>”><% $Default
%><%$message%><%$signature%>

ROWS=15 WRAP=HARD NAME="<%$Name%>"><% $Default

%><%$message%><%$signature%>

But I am still testing how it will behave :slight_smile:

RESULTS SO FAR:

If I now enter a very long URL via the the MessageBox (… creating a
ticket manually) it does what I expect. The URL is fully usable and don’t
gets wrapped by Text::Wrapper (you’ll get a horizontal scrollbar in your
browser then) the rest of the message body looks nice too (as formatted by
staff-members) and is unchanged.
Same result if RT receives the mail via the mailgateway.

While doing some furthers test now … i would like to add, that there
must be sth wrong with Text::Wrapper at all ?

TestScenario:

Building tickets via mailgateway without formatting the text…

Result:

Well - looks OK. My Mailer (PINE in this example) wrapped words to
the next line by itself … and so it is displayed in the ticket too.
Very long lines are unchanged by PINE (thought they must be processed by
Text::Wrapper ?) and these long lines are displayed in the same way I
entered 'em via PINE. (might result in a scrollbar in your browser to
view the whole content of such a long line)

Overall behaviour seems to be OK.

Test Scenario:

Building such tickets manually with the WebRT-Userinterface

Result:

Looks nice too… the text gets wrapped as defined in MessageBox after
72 charracters ($Width => 72) and I can also format it by myself with
hitting ENTER at the appropriate places…

Overall behaviour seems to be OK.

Final Result:

Imho will changing the code in ‘MessageBox’:

cruncher# diff MessageBox MessageBox.ORIGINAL
1c1
< <TEXTAREA COLS=<%$Width%> ROWS=15 WRAP=SOFT NAME=“<%$Name%>”><% $Default
%><%$message%><%$signature%>

ROWS=15 WRAP=HARD NAME="<%$Name%>"><% $Default

%><%$message%><%$signature%>

bring best results and break nothing.

I would like to ask you and other subscribers at devel to test this
too in a safe environment (so that nothing important would be broken if
i am wrong with my solution for this)… for me it works fine now and
i have no trouble with unusable long URL’s now.

Thanks for your time looking into this.

Friendly regards,

Frank Reppin

Heidestr. 15
39112 Magdeburg

Thanks for the sleuthing.

This does leave us with the question about whether soft or hard

wrapping is “the right thing” there, since email messages aren’t automatically
wrapped on generation. ISTR that I used to have soft wrapping the default
and people complained because users were getting run-on emails :confused:
Anyone got a brilliant idea?

JOn Thu, Feb 14, 2002 at 07:35:02PM +0100, Frank Reppin wrote:

On Thu, 14 Feb 2002, Jesse Vincent wrote:

Interesting. Text::Wrapper isn’t supposed to break words that don’t
fit on one line. The best place to play around with this is
WebRT/html/Ticket/Elements/ShowTransaction. you might want to try
switching the order of the URL escaping and the text wrapping.
If that works, I’ll happily make the switch in my sources.

-j

Hi,

another - maybe much more useful point to change this behaviour
seems to be in (leaving /rt2/WebRT/html/Ticket/Elements/ShowTransaction
untouched)

/rt2/WebRT/html/Elements/MessageBox

i made a simple change there …

cruncher# diff MessageBox MessageBox.ORIGINAL
1c1
< <TEXTAREA COLS=<%$Width%> ROWS=15 WRAP=SOFT NAME=“<%$Name%>”><% $Default
%><%$message%><%$signature%>

ROWS=15 WRAP=HARD NAME="<%$Name%>"><% $Default

%><%$message%><%$signature%>

But I am still testing how it will behave :slight_smile:

RESULTS SO FAR:

If I now enter a very long URL via the the MessageBox (… creating a
ticket manually) it does what I expect. The URL is fully usable and don’t
gets wrapped by Text::Wrapper (you’ll get a horizontal scrollbar in your
browser then) the rest of the message body looks nice too (as formatted by
staff-members) and is unchanged.
Same result if RT receives the mail via the mailgateway.

While doing some furthers test now … i would like to add, that there
must be sth wrong with Text::Wrapper at all ?

TestScenario:

Building tickets via mailgateway without formatting the text…

Result:

Well - looks OK. My Mailer (PINE in this example) wrapped words to
the next line by itself … and so it is displayed in the ticket too.
Very long lines are unchanged by PINE (thought they must be processed by
Text::Wrapper ?) and these long lines are displayed in the same way I
entered 'em via PINE. (might result in a scrollbar in your browser to
view the whole content of such a long line)

Overall behaviour seems to be OK.

Test Scenario:

Building such tickets manually with the WebRT-Userinterface

Result:

Looks nice too… the text gets wrapped as defined in MessageBox after
72 charracters ($Width => 72) and I can also format it by myself with
hitting ENTER at the appropriate places…

Overall behaviour seems to be OK.

Final Result:

Imho will changing the code in ‘MessageBox’:

cruncher# diff MessageBox MessageBox.ORIGINAL
1c1
< <TEXTAREA COLS=<%$Width%> ROWS=15 WRAP=SOFT NAME=“<%$Name%>”><% $Default
%><%$message%><%$signature%>

ROWS=15 WRAP=HARD NAME="<%$Name%>"><% $Default

%><%$message%><%$signature%>

bring best results and break nothing.

I would like to ask you and other subscribers at devel to test this
too in a safe environment (so that nothing important would be broken if
i am wrong with my solution for this)… for me it works fine now and
i have no trouble with unusable long URL’s now.

Thanks for your time looking into this.

Friendly regards,

Frank Reppin


Heidestr. 15
39112 Magdeburg

http://www.bestpractical.com/products/rt – Trouble Ticketing. Free.

“JV” == Jesse Vincent jesse@bestpractical.com writes:

JV> Thanks for the sleuthing.
JV> This does leave us with the question about whether soft or hard
JV> wrapping is “the right thing” there, since email messages aren’t automatically
JV> wrapped on generation. ISTR that I used to have soft wrapping the default
JV> and people complained because users were getting run-on emails :confused:
JV> Anyone got a brilliant idea?

Nothing will work globally. Some browsers automatically hard-wrap
textareas, others don’t wrap at all. Some honor the WRAP preference
in the textarea form field, others do not.

Basically, you’re screwed, since you don’t know whether the text
should be wrapped or not. Things like log lines shouldn’t be, while
plain text probably should be.

Perhaps Text::Autoformat can help. It seems almost magical
sometimes. But I don’t know if it will deal with log lines and such
things.

I’d say do the wrapping in ShowTransaction.
The ‘wrap’ attribute isn’t part of the HTML specs, so you can’t guarantee
it’ll perform correctly.
-Feargal.

At 19:29 14/02/02, Jesse Vincent wrote:

Thanks for the sleuthing.

    This does leave us with the question about whether soft or hard

wrapping is “the right thing” there, since email messages aren’t automatically
wrapped on generation. ISTR that I used to have soft wrapping the default
and people complained because users were getting run-on emails :confused:
Anyone got a brilliant idea?

    J

Interesting. Text::Wrapper isn’t supposed to break words that don’t
fit on one line. The best place to play around with this is
WebRT/html/Ticket/Elements/ShowTransaction. you might want to try
switching the order of the URL escaping and the text wrapping.
If that works, I’ll happily make the switch in my sources.

-j

Hi,

another - maybe much more useful point to change this behaviour
seems to be in (leaving /rt2/WebRT/html/Ticket/Elements/ShowTransaction
untouched)

/rt2/WebRT/html/Elements/MessageBox

i made a simple change there …

cruncher# diff MessageBox MessageBox.ORIGINAL
1c1
< <TEXTAREA COLS=<%$Width%> ROWS=15 WRAP=SOFT NAME=“<%$Name%>”><% $Default
%><%$message%><%$signature%>

ROWS=15 WRAP=HARD NAME="<%$Name%>"><% $Default

%><%$message%><%$signature%>

But I am still testing how it will behave :slight_smile:

RESULTS SO FAR:

If I now enter a very long URL via the the MessageBox (… creating a
ticket manually) it does what I expect. The URL is fully usable and don’t
gets wrapped by Text::Wrapper (you’ll get a horizontal scrollbar in your
browser then) the rest of the message body looks nice too (as formatted by
staff-members) and is unchanged.
Same result if RT receives the mail via the mailgateway.

While doing some furthers test now … i would like to add, that there
must be sth wrong with Text::Wrapper at all ?

TestScenario:

Building tickets via mailgateway without formatting the text…

Result:

Well - looks OK. My Mailer (PINE in this example) wrapped words to
the next line by itself … and so it is displayed in the ticket too.
Very long lines are unchanged by PINE (thought they must be processed by
Text::Wrapper ?) and these long lines are displayed in the same way I
entered 'em via PINE. (might result in a scrollbar in your browser to
view the whole content of such a long line)

Overall behaviour seems to be OK.

Test Scenario:

Building such tickets manually with the WebRT-Userinterface

Result:

Looks nice too… the text gets wrapped as defined in MessageBox after
72 charracters ($Width => 72) and I can also format it by myself with
hitting ENTER at the appropriate places…

Overall behaviour seems to be OK.

Final Result:

Imho will changing the code in ‘MessageBox’:

cruncher# diff MessageBox MessageBox.ORIGINAL
1c1
< <TEXTAREA COLS=<%$Width%> ROWS=15 WRAP=SOFT NAME=“<%$Name%>”><% $Default
%><%$message%><%$signature%>

ROWS=15 WRAP=HARD NAME="<%$Name%>"><% $Default

%><%$message%><%$signature%>

bring best results and break nothing.

I would like to ask you and other subscribers at devel to test this
too in a safe environment (so that nothing important would be broken if
i am wrong with my solution for this)… for me it works fine now and
i have no trouble with unusable long URL’s now.

Thanks for your time looking into this.

Friendly regards,

Frank Reppin


Heidestr. 15
39112 Magdeburg


http://www.bestpractical.com/products/rt – Trouble Ticketing. Free.


rt-devel mailing list
rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel

Feargal Reilly,
Systems Administrator,
The CIA.

I’d say do the wrapping in ShowTransaction.
The ‘wrap’ attribute isn’t part of the HTML specs, so you can’t guarantee
it’ll perform correctly.

There’s something to be said for wrapping outgoing mail as well; one
wouldn’t want one’s support desk sending single-incredibly-long-line
mail because the UI didn’t make it clear that that was going to
happen. :frowning:

-Rich

Rich Lafferty --------------±----------------------------------------------
Ottawa, Ontario, Canada | Save the Pacific Northwest Tree Octopus!
http://www.lafferty.ca/ | Save The Pacific Northwest Tree Octopus
rich@lafferty.ca -----------±----------------------------------------------

I’d say do the wrapping in ShowTransaction.
The ‘wrap’ attribute isn’t part of the HTML specs, so you can’t guarantee
it’ll perform correctly.

There’s something to be said for wrapping outgoing mail as well; one
wouldn’t want one’s support desk sending single-incredibly-long-line
mail because the UI didn’t make it clear that that was going to
happen. :frowning:

Yup. “Don’t”.

Send a customer a broken URL (by wrapping) and see what happens :wink:

                         Bruce Campbell                            RIPE
               Systems/Network Engineer                             NCC
             www.ripe.net - PGP562C8B1B                      Operations