Closed
Bug 126259
Opened 23 years ago
Closed 22 years ago
composer creates "underlined blanks" after pictures with link
Categories
(Core :: DOM: Editor, defect)
Tracking
()
VERIFIED
FIXED
Future
People
(Reporter: RainerBielefeldNG, Assigned: akkzilla)
References
()
Details
(Keywords: fonts, html4)
Attachments
(1 file)
(deleted),
patch
|
akkzilla
:
review+
kinmoz
:
superreview+
|
Details | Diff | Splinter Review |
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
Updated•23 years ago
|
Target Milestone: mozilla0.9 → ---
Reporter | ||
Comment 1•23 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
Reporter | ||
Comment 2•23 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
Reporter | ||
Comment 3•23 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•23 years ago
|
||
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?
Assignee: syd → attinasi
Component: Editor: Composer → Layout
Reporter | ||
Updated•23 years ago
|
Reporter | ||
Comment 6•23 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•23 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.
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".
Comment 8•22 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•22 years ago
|
||
Sounds like a dupe of bug 137799.
Comment 10•22 years ago
|
||
This will fix it.
Comment 11•22 years ago
|
||
-> editor for evaluation.
Assignee: attinasi → kin
Status: UNCONFIRMED → NEW
Component: Layout → Editor: Core
Ever confirmed: true
Keywords: patch
Assignee | ||
Comment 12•22 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+
Assignee | ||
Comment 13•22 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
Assignee | ||
Comment 14•22 years ago
|
||
*** Bug 137799 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 15•22 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).
Status: NEW → ASSIGNED
Comment 16•22 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.
Assignee | ||
Comment 17•22 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.
Assignee | ||
Updated•22 years ago
|
Whiteboard: patch, needs sr
Assignee | ||
Comment 18•22 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•22 years ago
|
||
same as bug 20163?
Reporter | ||
Comment 20•22 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•22 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•22 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.
Assignee | ||
Comment 23•22 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
Reporter | ||
Comment 24•22 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
http://gair.firstpr.com.au/public-files/moz-bug-space-in-linked-image/test-1.htm
should be worked fist
Target Milestone: Future → mozilla1.0.1
Assignee | ||
Comment 25•22 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
Assignee | ||
Comment 26•22 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•22 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.
Assignee | ||
Comment 28•22 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•22 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•22 years ago
|
||
Comment on attachment 84888 [details] [diff] [review]
patch to remove <img> from LineBreakAfterOpen
sr=kin@netscape.com
Attachment #84888 -
Flags: superreview+
Assignee | ||
Comment 31•22 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
Assignee | ||
Comment 32•22 years ago
|
||
Really marking fixed.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment 33•22 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:
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
Comment 34•22 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
bug.
Comment 35•22 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
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.
Comment 36•22 years ago
|
||
*** Bug 134462 has been marked as a duplicate of this bug. ***
You need to log in
before you can comment on or make changes to this bug.
Description
•