Closed Bug 50348 Opened 24 years ago Closed 17 years ago

alert() condenses groups of whitespaces to one single whitespace

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: taras.tielkes, Unassigned)

References

Details

(Keywords: dom0)

Attachments

(6 files)

testcase
360 bytes, text/html
Details
testcase with prompt()
361 bytes, text/html
Details
testcase with confirm()
363 bytes, text/html
Details
Proof-of-concept patch -- only fixes alert()
1.12 KB, patch
Details | Diff | Splinter Review
Testcase for spaces contracting HTMLOptionElements.
2.70 KB, text/html
Details
Testcase alert with two different methods
948 bytes, text/html
Details 
Don't know if this is the right component, but since alert() in mentioned in 
the ECMA spec...

It seems the current implementation of alert() on windows will remove leading 
and trailing spaces from the alert message. This prevents doing simple layout 
of the text displayed in the alert window. For instance, when parsing xml, a 
few spaces extra can be used to indicate a 'depth level' for a node.

IE5 seems to preserve leading and trailing spaces, this is very small, but 
useful piece of functionality.
Reassigning owner to match currently assigned component (DOM Level 0)
Assignee: rogerl → jst
Component: Javascript Engine → DOM Level 0
QA Contact: pschwartau → desale
danm, I don't know if this really belongs to you or not, if not please just
reassign...

I think this could be fixed with some CSS love in the CSS for the XUL that makes
up the alert dialog, specifically we'd need to add "white-space: pre;" somewhere...
Assignee: jst → danm
->future, possibly won'tfix.
Target Milestone: --- → Future
So is there a workaround for indenting alert() output?
Not that I know of.  cc jrgm
I better comment before I forget ... you can't simply set this to 
"whitespace: pre", since that alert dialog will wrap text, breaking lines
if no word break is available. Or alternatively, you could make it "whitespace: 
pre" if you preprocessed long lines to do that word-breaking. 

I did some JS code to do that on the weekend, but I'm not sure:
1) if that is i18n friendly (i.e, I was breaking on '\s' == [\n\t\f\r\v])
2) commondialog.xul is used by more than alert(), and I don't know offhand 
   if changing the layout of text for these other dialogs would be OK (might
   be fine, but need to check). 
... and there isn't a workaround (or not one easily available from a web page): 
the argument to alert(arg) is appended line-by-line to an <html> element, 
which, right now, means you get HTML layout rules for that text.
alert(), prompt(), etc also collapse multiple spaces to one space.  Should that 
be a separate bug?
Keywords: dom0
Summary: alert() will string leading and trailing whitespace of parameter → alert() strips leading and trailing whitespace of parameter
*** Bug 73965 has been marked as a duplicate of this bug. ***
*** Bug 93462 has been marked as a duplicate of this bug. ***
Not just leading or trailing whitespace, but every group of whitespaces is
condensed to one single whitespace ==> so the change of summary.

There's one workaround for this: use \xA0 like this:
alert("Hello.\xA0\xA0\xA0\xA0\xA0\xA0Hello");
Summary: alert() strips leading and trailing whitespace of parameter → alert() condenses groups of whitespaces to one single whitespace
*** Bug 166349 has been marked as a duplicate of this bug. ***
Blocks: 99615
We could use -moz-pre-wrap for the white-space: style... we could also control
this via a param in the dialogparams, which should at least limit it to things
posed via Alert().

Now I don't know whether we want everything calling through
nsIPromptService.alert() to keeps spaces or just things coming through
window.alert.  If the latter, we had better act promptly; that may require
changes to nsIPromptService/nsIPrompt, and the latter is UNDER_REVIEW.  Also see
bug 99615.

Note that nsIPromptService.alert() seems to keep the whitespace in at least
Chimera and probably other embedding apps...
I'm wondering why this component is called DOM0.  W3C didn't define (or care
about) this, so we're free to call it with a more suitable name.  Couldn't we
call it BOM (Browser Object Model) or NOM (Navigator Object Model) rather than
DOM0?  The letter 'D' in DOM would just invoke the notion of document in my mind
which is IMO confusing.
You couldn't be more off-topic, could you. And, apparently, you haven't even 
read the DOM specifications or you wouldn't have asked such a pointless 
question. 

In the future, restrict your comments to the specifics of a given bug report.
This is not a discussion forum.

Certainly it's offtopic, but the question isn't as pointless as that.  I've
looked at DOM1 and DOM2 too but I can't find any reference to DOM0.  I would
like to see any official reference to that.  I think what I'm going to say will
certainly enrage a lot of people, but in Microsoft's books or Wrox's books, they
do use the term "Browser Object Model".

Following blindly the others without even thinking if it's right or wrong isn't
a good attitude of learning (or whatever).
>I can't find any reference to DOM0

there is none. which is why we try to follow other browsers.
OK. Let's get two things straight.

1)  There is no specification for DOM0
2)  There are plenty of places that define what DOM0 is.  The glossary in the DOM2
    Events spec, for example.
>the argument to alert(arg) is appended line-by-line to an <html> element, 
>which, right now, means you get HTML layout rules for that text.
So if you do a replace on all "  " (two spaces) and change them into " &nbsp;"
(space and non-breaking space HTML entity), won't that solve this entire issue
without forcing us poor ol' scripters to use the UNICODE workaround?
No, because it's just appended as a raw string.  It's not parsed, and no entity
expansion is performed as a result.  We _could_ do entity expansion on the
string if we wanted to, I guess.  But since IE and NS4 do not, that would
actually lead to undesired behavior in many cases.
Hmmm, not sure I understand you completely. 

This is how I see it - I haven't looked at the source because that would most
likely make me jump off a cliff.

1) The HTML page contains something like 
   <script type="text/javascript">
       alert("what is  up  with the spaces & stuff?");
   </script>

2) Mozilla makes an HTML document for the alert box, say (quick & dirty):
   <html><head><title>[JS App]</title></head>
   <body><p>what is  up  with the spaces & stuff?</p></body></html>

3) The output is the alert box like we all know it, with condensed spaces

--

When I say 
>"  " (two spaces) and change them into " &nbsp;"
I don't mean the <script> in the calling HTML page has to be changed, but in the
resulting output page. So step 2) would become:

2) Mozilla makes an HTML document for the alert box, say (quick & dirty):
   <html><head><title>[JS App]</title></head>
   <body><p>what is &nbsp;up &nbsp;with the spaces &amp; stuff?</p></body></html>

Mozilla itself has to do the HTML entitizing (ahem), not the developer.

When you say
>It's not parsed, and no entity expansion is performed as a result
it seems you thought I meant that alert("&amp;") would show up as an alert box
containing the text "&" (without the quotes). Right?
Yes.  Ok, I misunderstood you.  Sure, we could replace all the spaces with the
&nbsp; character in the string. This could be done in window.alert() if we
wished and so would not involve the prompt service...
>Sure, we could replace all the spaces with the &nbsp; character in the string.
My brain reads this to me with a Homer Simpson-like voice, and thus makes it
sound ironic. So: is there a big but?

And isn't there a way to do it for both the alert() and confirm() boxes?

Incidentally: tabs (\t) don't work either. Not handy when debugging scripts. And
you don't have to replace ALL spaces (in fact: that would mean the text would
not get wrapped at all) just every second space in a pair of two spaces. And
replace the tabs with the application default number of spaces.

Test URL: javascript:alert('one space\ntwo  spaces\n\nno tab\none\ttab');
The big but was text wrapping.  The "every other space" approach _may_ work 
there, yes...
*** Bug 172672 has been marked as a duplicate of this bug. ***
Re comment #18:
I've seen that glossary, but that isn't exactly a definition of DOM0.  It just
mentions that somebody else is using this term.  That said, it's nothing official.

Sorry for the off-topic :p
danm, Boris, does my suggestion work? I'm sorry, but I can't try it myself - no
Mozilla hacking for me. Comment #3 is really frightening:
"->future, possibly won'tfix."
OK.  So does this only apply to alert() or to prompt() also?

We should decide whether we want this only for JS window.alert() or also for
Alert().  Dan?  jst?
Attached file testcase — 
I wonder why no one bothered to attach one of these puppies...
This doesn't give us 4xp since NS4 does not wrap at _all_.  This does not give
us IE parity, since in IE a tab seems to be expanded to 8 spaces.  I do not
think we should be emulating the NS4 behavior; dunno about the IE one.	That
one would be easiest with the -moz-pre-wrap solution.

Thoughts?  I suppose prompt() and confirm() could be hacked the same way...

But we should once again decide what level this should be implemented on.
One other thing.  The impact of that patch on embedded builds needs to be looked
at if we decide to do this in nsGlobalWindow.
Here is another instance of unnecessary space contraction.
Actually, I believe HTMLOptionElement is the seperate (but related) concern of
Bug 30471.
This shows the alert() in two different ways. The first way just alerts the
following text: "	      <- Where are my spaces?" (minus the quotes)
The second one grabs <pre> element PRE1 from the DOM and alerts it. It then
places it in PRE2. As you can see, they don't match, thus misleading someone
who would use alert() for testing.
No longer blocks: 99615
*** Bug 195663 has been marked as a duplicate of this bug. ***
*** Bug 232496 has been marked as a duplicate of this bug. ***
On windows \t isn't just 8 spaces:
Tab marks are set every 8 characters (of average character width) and a 
tab-escape advances to the next tab-mark.

This WinAPI call shows the difference:
::MessageBox(0, "12345678XX\n        XXXX        YY\n
"ZZ        XXX        YY\n"
"\tXX\tYY\nZZ\tXXXXX\tYY",0,MB_OK);

When using a &nbsp; replacement i suggest for n spaces i suggest n-1 nsbp
followed by a normal space.

Another idea:
Replace a spaces by <span style="width: #pt;"> </span>
where # is the width of the space, (maybe "width: 1em;" is ok too)

Same strategy could work for tabs but needs postprocessing.

I suggest these steps:
1. get the width of the space character  (sw) and the average with of a
character (aw)
2. surround spaces with <span id=space></span> and tabs <span id=tab></span>
2. do normal layout for the message box
3. loop through all space spans and adjust the width:
     width=sw*<number of spaces>
4: loop through all ab spans and adjust the width:
     width= aw*8 - left % aw*8

sw =  get the width of space in "<span id=space> </span>"
aw =  get the width of "<span id=abc>ABCDEFGHIJKMNOPQRSTUVWXYZ</span>"

Or use a better way to get aw/sw if you know one.

Finally, i suggest replacing "\n" by <br> and use a single HTML element in the
alert/confirm boxes.
> 1. get the width of the space character  (sw) and the average with of a
> character (aw)

Not doable from the code that poses the alert -- this information is private to
the layout engine.  Note that the layout engine _does_ support tab stops for tab
chars in certain modes (eg in white-space: pre) so handling tabs should just
happen in there anyway.
(In reply to comment #39)
> On windows \t isn't just 8 spaces:

that should be the case everywhere.
*** Bug 261231 has been marked as a duplicate of this bug. ***
I come to this discution to recall that blank spaces in Alert window texts are 
useful for many purposes, mainly to trim and adjust the text position.
See http://http://www.shedrupling.org/art/lotr/image.php with Firefox (text is 
right aligned) and with IE (Text is centered).

Using &nbsp; in place of blank spaces  as suggested by Jan! (comment 19) do not 
work with IE and no more with netscape. So it cannot be the solution with 
Firefox. 
*** Bug 272410 has been marked as a duplicate of this bug. ***
Assignee: danm.moz → nobody
Assignee: nobody → general
OS: Windows NT → All
Priority: P3 → --
QA Contact: desale → ian
Hardware: PC → All
Target Milestone: Future → ---
can we close this as in
  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) 
  Gecko/2007092204 Minefield/3.0a9pre

alert, prompt, confirm preserve multiple whitespace ie, space, \t, \n

But the test case on HTMLOptionElements still fails.
Depends on: 60513
Bug 60513 doesn't seem to have anything to do with this bug.  The dependency should be removed.  Any objection?
Yeah, the dependancy to bug 60513 can be removed.
The alert issue was already longer fixed before bug 60513 was fixed.

I think the bug for the HTMLOptionElements is bug 30471.

So basically, I think this bug can be marked worksforme.
No longer depends on: 60513
OK, marked FIXED (but certainly not Workforme because some corrections had indeed been incorporated to solve this problem)
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Yes, but it's not clear what bug fixed this, so that's why it should be worksforme.
If you can find out what bug fixed this, then you can mark this bug fixed.
Resolution: FIXED → WORKSFORME
According to Bugzilla's official definition:
WORKSFORME
    All attempts at reproducing this bug were futile, and reading the code produces no clues as to why the described behavior would occur. If more information appears later, the bug can be reopened.

In other words, it's not sure if the bug in question ever existed or if it is reproducible.

However, as far as this bug is concerned, it is 100% sure a real bug and reproducible.  The fact that some "mysterious force" fixed this bug isn't a problem (as a matter of fact, a lot of other bugs are corrected like this!).  So it shouldn't be marked as Workforme which would mislead future readers/maintainers to think that this bug wasn't one.
Resolution: WORKSFORME → FIXED
Well, I think that description is too narrow.
https://bugzilla.mozilla.org/page.cgi?id=fields.html#status

WORKSFORME is also used for bugs that used to be bugs, but were fixed in an unknown way.

I filed bug 399463 for getting that into the definition.

I'll leave this bug alone for now, it's useless to have a resolution war.
Hmmm... thanks to all who worked on this.

But I feel somewhat frustrated, because we don't know how it was fixed. Surely the alert() functionality uses some function x() to display the text. If the function x() is also expected to display several blank spaces, everything is OK. But if the function x() is NOT expected to display those blanks, it will be corrected one day, and this bug on this page will reappear.
This could be checked by looking at the table of functions use (a complete list of which functionalities use each function x(), y(), z()... etc). But I am not an insider to guess where this table is.

Also, in my comment 43, I stated that using &nbsp; to trim text in place of ordinary spaces, was not a solution because it don't work with Netscape and neither with Internet Explorer. Things have changed today, netscape is virtually disappeared, and Internet Explorer is no longer in the position of setting its (bad) standards. Today we must be coherent with Opera and Safari. So we can think at much better solutions, for instance: 1) trim groups of blanks to be consistent with the HTML 2) not trim groups of &nbsp; to still allow to adjust the text.   
It was probably fixed by bug 317334.
In reply to comment #53:
Your image in comment #43 is no longer available so it's not possible to understand your viewpoint.  You should have uploaded it for this bug.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: