Closed Bug 50348 Opened 22 years ago Closed 15 years ago
alert() condenses groups of whitespaces to one single whitespace
360 bytes, text/html
361 bytes, text/html
363 bytes, text/html
1.12 KB, patch
|Details | Diff | Splinter Review|
2.70 KB, text/html
948 bytes, text/html
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
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?
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. ***
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 " " (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.
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...
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?
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.
*** 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 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 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: 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.
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: 15 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 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.
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.