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)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
FIXED
People
(Reporter: taras.tielkes, Unassigned)
References
Details
(Keywords: dom0)
Attachments
(6 files)
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.
Comment 1•24 years ago
|
||
Reassigning owner to match currently assigned component (DOM Level 0)
Assignee: rogerl → jst
Component: Javascript Engine → DOM Level 0
QA Contact: pschwartau → desale
Comment 2•24 years ago
|
||
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
Reporter | ||
Comment 4•24 years ago
|
||
So is there a workaround for indenting alert() output?
Comment 5•24 years ago
|
||
Not that I know of. cc jrgm
Comment 6•24 years ago
|
||
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).
Comment 7•24 years ago
|
||
... 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.
Comment 8•24 years ago
|
||
alert(), prompt(), etc also collapse multiple spaces to one space. Should that be a separate bug?
Updated•24 years ago
|
Summary: alert() will string leading and trailing whitespace of parameter → alert() strips leading and trailing whitespace of parameter
Comment 10•23 years ago
|
||
*** Bug 93462 has been marked as a duplicate of this bug. ***
Comment 11•22 years ago
|
||
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
![]() |
||
Comment 12•22 years ago
|
||
*** Bug 166349 has been marked as a duplicate of this bug. ***
![]() |
||
Comment 13•22 years ago
|
||
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...
Comment 14•22 years ago
|
||
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.
Comment 15•22 years ago
|
||
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.
Comment 16•22 years ago
|
||
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).
Comment 17•22 years ago
|
||
>I can't find any reference to DOM0
there is none. which is why we try to follow other browsers.
![]() |
||
Comment 18•22 years ago
|
||
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.
Comment 19•22 years ago
|
||
>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 " "
(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?
![]() |
||
Comment 20•22 years ago
|
||
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.
Comment 21•22 years ago
|
||
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 " " 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 up with the spaces & 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("&") would show up as an alert box containing the text "&" (without the quotes). Right?
![]() |
||
Comment 22•22 years ago
|
||
Yes. Ok, I misunderstood you. Sure, we could replace all the spaces with the character in the string. This could be done in window.alert() if we wished and so would not involve the prompt service...
Comment 23•22 years ago
|
||
>Sure, we could replace all the spaces with the 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');
![]() |
||
Comment 24•22 years ago
|
||
The big but was text wrapping. The "every other space" approach _may_ work there, yes...
![]() |
||
Comment 25•22 years ago
|
||
*** Bug 172672 has been marked as a duplicate of this bug. ***
Comment 26•22 years ago
|
||
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
Comment 27•22 years ago
|
||
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."
![]() |
||
Comment 28•22 years ago
|
||
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?
![]() |
||
Comment 29•22 years ago
|
||
I wonder why no one bothered to attach one of these puppies...
![]() |
||
Comment 30•22 years ago
|
||
![]() |
||
Comment 31•22 years ago
|
||
![]() |
||
Comment 32•22 years ago
|
||
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.
![]() |
||
Comment 33•22 years ago
|
||
One other thing. The impact of that patch on embedded builds needs to be looked at if we decide to do this in nsGlobalWindow.
Comment 34•22 years ago
|
||
Here is another instance of unnecessary space contraction.
Comment 35•22 years ago
|
||
Actually, I believe HTMLOptionElement is the seperate (but related) concern of Bug 30471.
Comment 36•22 years ago
|
||
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.
![]() |
||
Comment 37•22 years ago
|
||
*** Bug 195663 has been marked as a duplicate of this bug. ***
![]() |
||
Comment 38•21 years ago
|
||
*** Bug 232496 has been marked as a duplicate of this bug. ***
Comment 39•21 years ago
|
||
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 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.
![]() |
||
Comment 40•21 years ago
|
||
> 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.
Comment 41•21 years ago
|
||
(In reply to comment #39) > On windows \t isn't just 8 spaces: that should be the case everywhere.
Comment 42•20 years ago
|
||
*** Bug 261231 has been marked as a duplicate of this bug. ***
Comment 43•20 years ago
|
||
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 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.
![]() |
||
Comment 44•20 years ago
|
||
*** Bug 272410 has been marked as a duplicate of this bug. ***
Updated•18 years ago
|
Assignee: nobody → general
OS: Windows NT → All
Priority: P3 → --
QA Contact: desale → ian
Hardware: PC → All
Target Milestone: Future → ---
Comment 45•17 years ago
|
||
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
Comment 46•17 years ago
|
||
But the test case on HTMLOptionElements still fails.
Comment 47•17 years ago
|
||
Bug 60513 doesn't seem to have anything to do with this bug. The dependency should be removed. Any objection?
Comment 48•17 years ago
|
||
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
Comment 49•17 years ago
|
||
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
Comment 50•17 years ago
|
||
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
Comment 51•17 years ago
|
||
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
Comment 52•17 years ago
|
||
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.
Comment 53•17 years ago
|
||
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 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 to still allow to adjust the text.
Comment 54•17 years ago
|
||
It was probably fixed by bug 317334.
Comment 55•17 years ago
|
||
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.
Description
•