Closed Bug 399321 Opened 17 years ago Closed 17 years ago

Should there be the pref whether URLs are breakable?

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: masayuki, Assigned: masayuki)

References

Details

Attachments

(1 file, 1 obsolete file)

Patch for after '/' breaking
2.41 KB, patch
Details | Diff | Splinter Review 
Some Western users may not like URLs being breakable. But I don't know whether the users are many. Therefore, I cannot decide the best way for this.

There are following ways:

1. the default value of the pref is true (URLs are breakable).
2. the default value of the pref is false (URLs are not breakable) and it is localizable (At least, the default value is true on Japanese localized build).

I had another idea. We use the lang attribute for it. But it will confuse the users. And the URL is not in a natural language...

However, I have some issues:

1. The reftests for line-breaking (posted in bug 389056) cannot test both pattern. (Should I remove the URL breaker testing from them?)
2. By the users, the layout result is changed. (Especially, when we use the second way.)
Flags: blocking1.9?
Summary: Should there be the pref whether URLs are breakable → Should there be the pref whether URLs are breakable?
Once reftests run against a separate profile, we can actually test both patterns.  Just need to set the pref accordingly across the test.
(In reply to comment #1)
> Once reftests run against a separate profile, we can actually test both
> patterns.  Just need to set the pref accordingly across the test.

Can we do it on current system? It seems that the reftests cannot refer the prefs..

That's why I said "once reftests run against a separate profile".
I think it's a bad idea to make things like this depend on the language of the browser (but it's ok to make it depend on the language of the content) since it makes it very hard for Web authors to test and understand the browser's behavior.
Where's the pressure for this pref coming from? As a Western-language user, I'm finding URI-breaking very useful.
the pressure comes from the comment for bug 389056 and bug 398165 and the thread ("Line Breaking") of mozilla.dev.tech.layout.

I cannot judge whether the dissatisfied users are many. I want to hear the comments/suggestions of this issue.
I think that the "many" users don't like the URL breaker, we should change the breaker to switchable. But if not so, we should not create the pref for web designers.
Frankly, a better solution to bug 398165 would be to implement break prioritization.  Bug 389056 is being solved by not breaking before a closing '"', right?

The only real issue I have with the breaking behavior we have now is that it sometimes makes it difficult to tell where the URI ends in some cases.  And even that has been somewhat ameliorated by breaking before the '/' in the URI, not after it.

I do think that fixing bug 398165 would eliminate pretty much all my remaining issues with the behavior here.
(In reply to comment #8)
> Frankly, a better solution to bug 398165 would be to implement break
> prioritization.  Bug 389056 is being solved by not breaking before a closing
> '"', right?

I think to implement the prioritized line-breaking needs risky patch. So, it should be implemented after Gecko 1.9, not current cycle. (Or, can we implement it with safe way?)

# I hope that I'll work for new line-breaking in Gecko 2.0 cycle.

> The only real issue I have with the breaking behavior we have now is that it
> sometimes makes it difficult to tell where the URI ends in some cases.  And
> even that has been somewhat ameliorated by breaking before the '/' in the URI,
> not after it.

I hate the "before" too. With minor changes, I can fix it.
I agree that prioritization is a post-1.9 issue.

I'm not sure I follow the 'I hate the "before" too' part.  Breaking before the '/' instead of after makes it a little clearer where the URI ends.  Otherwise, consider this text:

  After going to http://www.mozilla.org/
  you can see that there is nothing there.

Is the URI "http://www.mozilla.org/" or "http://www.mozilla.org/you"?
I think that the last / should not be breakable. (And the second slash too. We should ignore it when the previous of slash is slash.)
Attached patch Patch for after '/' breaking (obsolete) — — Splinter Review 
Boris: see this patch.
er, this is correct, the previous has a mistake.
Attachment #284347 - Attachment is obsolete: true
Things like "look ahead through all the rest of our input" worry me... :(
Boris, based on comment #10, are you saying we shouldn't do anything here for 1.9?
I'm torn.  On the one hand, breaking the URIs is really weird; it catches me by surprise every time I paste one in a Bugzilla textarea.  On the other hand, I don't know how much of that is just over a decade of habituation; maybe once I get used to it it'll be a lot more natural....

I do think that for 1.9 we should either do nothing or have a user pref to not break on '/'.  Not sure how reasonable this last is, since it would be non-discoverable; I don't think this pref should have UI, for sure.
Is this really necessary?  As a "Western user", I quite used to seeing URIs broken across lines.  I actually prefer a broken URI -- if properly done -- over having a horizontal scrollbar.  By "properly done", I mean per Appendix C of RFC 3986.  

If those who write text with URIs would only follow Appendix C, broken URIs would be easily understood.  "Using <> angle brackets around each URI is especially recommended as a delimiting style for a reference that contains embedded whitespace."  This should be done in ALL CASES, not merely when the URI breaks.  

If Internet applications all recognized the <> delimiters, broken URIs would be usable.  "For robustness, software that accepts user-typed URI should attempt to recognize and strip both delimiters and embedded whitespace."  

How much effort should be expended to compensate for those who do not follow generally recognized conventions?  


David, I would agree if most people would use <> around URLs _and_ Mozilla would recognize and strip them. Both are not true. Even computer geeks (look through the mozilla.dev.* groups) don't use angle brackets. How do you want to force normal users?

In effect, there is no easy way to discriminate where an URL ends if it is broken. In cases where the browser knows where it ends and highlights it, that is no problem. But in other cases, especially in input fields, URLs are not highlighted, and it's often confusing.
fm, In Japan, many text editors can show the LF (or CR or CRLF) like "downwards arrow" symbol.

By this function, the users can recognize the end of lines are wrapped or broken.

The editor of Gecko should have this functions? If so, the confusion might not occur in editors.
Flags: blocking1.9? → blocking1.9-
-> INVA.

This is time over. We don't need to implement for most people. And in next version of Gecko, we should have new line breaker that has prioritized feature.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: