Problem ------- http://home.t-online.de/home/Bielefeld__Buss_oHG/mozilla/ex210.html You see little "underlined blanks", which cannot be removed. It seems, that there are no "real blanks", but there is a problem with the created html same effekt sometimes after Test with links. Problem does not apear allways immediately when I create a page, but after adding elemets step by step, suddenly the problem appears ant the first picture with link and then soon at more pictures. Problem is in M097, M098 and NS6.2. No Problem ----------- http://home.t-online.de/home/Bielefeld__Buss_oHG/mozilla/ex110.html correct link/graphic, created with netscape composer 4.7 Information: I Created ex110.html with NS4.7. then I Opened es110.html with composer mozilla 0.9.8 and saved the file as ex210.html The Problem appeared immedeately

Shurely one of those "pretty print" problems. After I disabled that preference, I was able to repair the pages by cleaning the "underlines" easyly. see also bug 127559

The "underlined Blanks" are shown, because the composer sets the '</a> - tag' to the next line in the html-source. That causes an "underlined Blank" after the picture with the link. The Problem still exists in mozilla 0.9.9.

It seems, that there have ben changes for "pretty print"- mode in Mozilla/5.0 (Windows; U; Win98; de-AT; rv:0.9.9+) Gecko/20020319(03), but the Problem ist still actual, and the "pretty print"- cource-text can not be read very easy!

There seem to be lots of problems with formated output, e.g., html code for tables is indented a ridiculous amount.

--> layout any idea why these two documents would render differently?

Reply to #5 in source-code of ex210.html you fint </a> tags in new lines what causes the underlined blanks

As noted above, this problem is caused by the closing tag of the hyperlink </a> being placed on the line after the image is specified. This newline is then, quite naturally, interpreted by the browser as a space. I think the fix will be in "Pretty Print" or whatever is part of, or associated with, the seralizer, which is adding newlines to the output file in an attempt to limit line lengths. I have created an example file which demonstrates this and which lists the perplexing discrepencies between various programs and situations which make this space visible by it being underlined as a link. http://gair.firstpr.com.au/public-files/moz-bug-space-in-linked-image/test-1.htm l But the problem is with the space (the newline before </a> in the HTML file) in the first place, whether or not it is made visible by link underlining. This space could upset the layout of the page, but in many instances it won't, or the disruption would not be noticed. One annoying thing is that Composer will not make the space visible with underlining when it creates the linked image (becase in its internal data, there is no space - the space is created by the serializer when writing the output file) - but when the same file is opened later in Composer, the underlined space is visible. Deleting the space will get rid of it, but it will be regenerated by the serializer when the file is saved. BTW, I am not sure why this bug is "Unconfirmed".

this bug is TM: *mozilla1.0* but still *unconfirmed* That doesn't seem right. It is also blocking bug 46227 (switching between "normal" and "html source" adds spaces), which is _not_ really fixed until _this_ bug is fixed.

Sounds like a dupe of bug 137799.

This will fix it.

-> editor for evaluation.

Comment on attachment 84888 [details] [diff] [review] patch to remove <img> from LineBreakAfterOpen r=akkana. I hate that we have to do this, but I guess we do.

Taking the bug (but burpmaster, if you want to own it, take it away, since the patch is yours). Kin, can you sr this one-line patch?

*** Bug 137799 has been marked as a duplicate of this bug. ***

Wait a minute. B.3.1 of the HTML 4.0 spec (SGML implementation notes) says: "SGML (see [ISO8879], section 7.6.1) specifies that a line break immediately following a start tag must be ignored, as must a line break immediately before an end tag." The patch eliminates the line break after the <IMG> start tag; but that line break shouldn't be shown anyway. Perhaps the problem isn't the line break, but that we're adding whitespace after the line break in order to indent the next tag? Not adding a newline after an IMG tag will lead to very long lines, so I'd like to keep the newline if we can (and eliminate the indenting spaces instead, if they are the problem).

I don't think that applies here. I believe that rule is there only so you can open a tag, put a newline and content, another newline, then close the tag, and the newlines will get ignored. Since the <img> tag closes itself, there's an imaginary </img> after it, and you don't ignore linebreaks after ending tags.

Oh, you're probably about that for the <img>\n<img> case (mentioned in bug 137799). It wouldn't explain why we see the underlined blank in the <a><img>\n</a> case: according to the spec, the newline should be invisible in that case. But code to identify the <img>\n[not close tag] case would be significantly more complicated, and failing that, we need an immediate fix. So we should probably check in your patch; but if it does go in I'll probably file bugs on the remaining issues (that we're showing whitespace that should be invisible, and making the serializer smart enough to recognize when a newline can be safely added once layout is smart enough to allow the space). Unless you convince me that I'm wrong in thinking those are bugs.

Kin, can you look at this, sr it if you think it's appropriate, and recommend someone who might be able to answer my questions about layout issues? Thanks!

same as bug 20163?

comment to #19 I think so. I marked this bug as "depends on 20163" Eventually "duplicate"? It should be made shure that work on all these bugs concerning the same problem will be concentrated.

If you want, you can try the patch for bug 1777. That patch should fix 20163, too, so if it is a dup.... The patch is currently awaiting review.

Comment on attachment 84888 [details] [diff] [review] patch to remove <img> from LineBreakAfterOpen Sorry for the delayed response. I really think we should hold out for a real fix for the underlying problem in layout (bug 20163 and bug 1777). The patch in this bug will only work around the problem for composer output, but html pages on the net will still show the same problems.

Thanks for commenting. I'm fine with that -- I agree that I'd prefer to see a fix for the real problem in layout. Unfortunately bug 20162 is marked Future (and is assigned to the wrong person, since most people in the bug agree that the fix shouldn't happen in the parser), and bug 1777 doesn't have a target milestone set, so this one will also have to be Future.

I do not see a serious browser-problem: all browsers show those underlines more or less in the same way, if they find a </a> in a new line afer the <a>- tag. solution as described in http://gair.firstpr.com.au/public-files/moz-bug-space-in-linked-image/test-1.htm should be worked fist

It is considered rude to change the target milestone of a bug you do not own. Please don't do that. Changing it back. If you can convince Kin or another sr'er that we should take this patch, then I'll pull it back in. There's nothing I can do at this point without an sr. I know NS4 shows the underscore. Can we get a listing of what other browsers (IE, opera, konqueror, icab) do?

Does this patch ensure that long img tags (more than 72 chars, which is common with a long url plus alt text) don't get wrapped purely because of the serializer's wrapping code? Or does it only work for short img tags, by not forcing a newline, but not solve the more common problem of long img tags?

I still think this patch should go in. If img is in LineBreakAfterOpen, Mozilla just adds linebreaks after the images blindly. There are cases where whitespace shouldn't be added because it will change the document, even if that spec was followed. The correct behavoir would be to make AppendElementEnd add a newline if the max column position has been exceeded.

I'm inclined to agree -- if nothing else, this patch will make it better in some cases (Kin?) -- but this patch alone probably isn't enough to mark the bug fixed (at least without testing to find out what happens in wrapping) since most real-world img tags are long enough that we will probably wrap right after the tag.

I've tested. It will only wrap after the tag if there is already a space there. Otherwise, it will continue on the same line until it finds a place to wrap at. So this fixes all cases of composer inserting spaces after images. If they're already there, you can delete them, and they won't come back.

Comment on attachment 84888 [details] [diff] [review] patch to remove <img> from LineBreakAfterOpen sr=kin@netscape.com

The fix has been checked in on the trunk. Even though I said it shouldn't close this bug, I decided it was better to file a more general bug to cover the wrapping problem: so I've done so, bug 154264.

Really marking fixed.

I don't think this bug is fixed yet. Build 2002070204 fixes the problem to an extent, in that the link is closed on the same line, rather than on the next, but in my test case there is an *additional* hyperlink after that, encompassing a newline in the HTML source. This does not appear to be visible in the browser/composer of Mozilla, N4.7x, MSIE6 or Opera6, but it is clearly something which is wrong, and should be looked into. My example is at: http://gair.firstpr.com.au/public-files/moz-bug-space-in-linked-image/t2.html Since there is line-wrapping in Bugzilla, the following is a truncated version of the result, with "XXX" showing where I chopped out inconsequential stuff: <a href="#Boo"><img src="XXX.jpg" alt="XXX" XXX border="0"></a><br> <a href="#Boo"> </a><br> There is no space - just "<a href="#Boo">NEWLINE</a><br>" I will leave someone else to look under the hood at the code. I am doing the eyeballs bit of "Given enough eyeballs, all bugs are shallow." - but I sense that the HTML spec for treating newlines as whitespace, and for treating more than one space as one whitespace, is a curse which will haunt us for a long time yet. - Robin

I doubt my patch could have caused this. I also couldn't reproduce it in win2k build 2002070108, but maybe it's new in your build. In any case, I'm sure it's a seperate issue, so if you can still reproduce it in the next build, file a new bug.

Sorry, I didn't see this bug any earlier. Oh, this is so late that the fix is checked-in also:-( This bug is same as the second part of the bug#107927. Please see http://bugzilla.mozilla.org/show_bug.cgi?id=107927#c7. Bug# 107927 is the place where we have all the relevant discussions... We had lot's of suggestions, concerns and finally we moved that bug to the Layout. I feel 107927 to be a critical bug which would solve *lots 'n' lots* of other bugs which are currently lying under "DOM-TXT serialization" and "Parser" as component.

*** Bug 134462 has been marked as a duplicate of this bug. ***

w4m, vrfy'ing with 2003.04.10.