composer creates "underlined blanks" after pictures with link




18 years ago
16 years ago


(Reporter: RainerBielefeldNG, Assigned: akkzilla)


({fonts, html4})

Windows 98
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




(1 attachment)



18 years ago
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
correct link/graphic, created with netscape composer 4.7

I Created ex110.html with NS4.7.
then I Opened es110.html with composer mozilla 0.9.8 and saved the file as
The Problem appeared immedeately


18 years ago
Keywords: fonts
Target Milestone: --- → mozilla0.9


18 years ago
Keywords: html4


18 years ago
Target Milestone: mozilla0.9 → ---

Comment 1

18 years ago
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

Comment 2

18 years ago
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.
Severity: normal → major
Target Milestone: --- → mozilla1.0

Comment 3

18 years ago
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!

Comment 4

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

Comment 5

17 years ago
--> layout

any idea why these two documents would render differently?
Assignee: syd → attinasi
Component: Editor: Composer → Layout

Comment 6

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

Comment 7

17 years ago
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.

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".


17 years ago
Blocks: 46227

Comment 8

17 years ago
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.

Comment 9

17 years ago
Sounds like a dupe of bug 137799.


17 years ago
Blocks: 137799

Comment 11

17 years ago
-> editor for evaluation.
Assignee: attinasi → kin
Component: Layout → Editor: Core
Ever confirmed: true
Keywords: patch

Comment 12

17 years ago
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.
Attachment #84888 - Flags: review+

Comment 13

17 years ago
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?
Assignee: kin → akkana
Target Milestone: mozilla1.0 → mozilla1.0.1


17 years ago
No longer blocks: 137799

Comment 14

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

Comment 15

17 years ago
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).

Comment 16

17 years ago
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.

Comment 17

17 years ago
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.


17 years ago
Whiteboard: patch, needs sr

Comment 18

17 years ago
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!

Comment 19

17 years ago
same as bug 20163?

Comment 20

17 years ago
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.
Depends on: 20163

Comment 21

17 years ago
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 22

17 years ago
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.

Comment 23

17 years ago
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.
Depends on: 1777
Whiteboard: patch, needs sr → Waiting for decision in 20163 or 1777
Target Milestone: mozilla1.0.1 → Future

Comment 24

17 years ago
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
should be worked fist
Target Milestone: Future → mozilla1.0.1

Comment 25

17 years ago
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?
Target Milestone: mozilla1.0.1 → Future

Comment 26

17 years ago
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?

Comment 27

17 years ago
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.

Comment 28

17 years ago
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.

Comment 29

17 years ago
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 30

17 years ago
Comment on attachment 84888 [details] [diff] [review]
patch to remove <img> from LineBreakAfterOpen
Attachment #84888 - Flags: superreview+

Comment 31

17 years ago
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.
Whiteboard: Waiting for decision in 20163 or 1777

Comment 32

17 years ago
Really marking fixed.
Closed: 17 years ago
Resolution: --- → FIXED

Comment 33

17 years ago
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:

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">

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

Comment 34

17 years ago
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

Comment 35

17 years ago
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

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 

Comment 36

17 years ago
*** Bug 134462 has been marked as a duplicate of this bug. ***
w4m, vrfy'ing with 2003.04.10.
You need to log in before you can comment on or make changes to this bug.