Closed Bug 167262 Opened 18 years ago Closed 17 years ago

style element background-image: composer makes relative links absolute

Categories

(SeaMonkey :: Composer, defect, P1)

defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.6beta

People

(Reporter: RainerBielefeldNG, Assigned: dbaron)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Keywords: css1, dataloss, Whiteboard: [patch][adt2] Don't comment unless you have a patch.)

Attachments

(2 files, 3 obsolete files)

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2a) Gecko/20020906 
(and all earlier I tested)

Steps to reproduce:

1. select "preferences/composer/"Use CSS-Styles instead..."
2. Create a new composer page and save it in a folder with a "background-image"
in   
   it 
3. select a any background-image by "Format/Background Colors....) and select
   "URL is relative"
4. <OK>
5. have a look to the source:
   expected: <body style="background-image: url(background.jpg);">
   actual: <body style="background-image: url(file:///D:/.../background.jpg);">

This is absolutely not senseful, because the page is published, there can be no
more access to that image.

Actual woraround: I can use absolute adresses like <body
style="background-image: url(http://home.t-online.de/home/martina-buss/corvi2.jpg)

Eventually helpful: look to bugfix for bug 122227
Severity: normal → major
Keywords: dataloss
-->brade
Assignee: syd → brade
*** Bug 184384 has been marked as a duplicate of this bug. ***
It seems to be a general bug because this happens with OS/2 as well as with
Windows 2000 and Windows XP too.

Trapper
Flags: blocking1.3b?
Flags: blocking1.3b? → blocking1.3b-
By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.
Severity: major → critical
This applies not only to background images, but any images.
Replicating the bug:

1) Create an image whose source is given as a relative link
   (and/or is linked to another object with a relative link)
2) Cut/copy it
3) Paste
4) Observe: relative links have become absolute

This on Mozilla 1.3alpha for Linux, but as previously noted probably
applies to all platforms.  The problem is particularly annoying because
the absolute links created are of the form file://, which means
that the corruption is not immediately noticeable and they break
everywhere *except* the creator's computer!
To #8
Might be that there are similar reasons for the problem you described and the
bug reported by me, but there are also several differences:
The Problem you described only is a handling problem: you can "reopen" the
pasted image and can make the reference absolute.
This is not possible with the background-images (created as described in the
bug-report), the composer will always make a relative link absolute again.

There was a similar problems with references for favicons like
<link rel="icon" href="../b.png" type="image/png">
In earlier builds this link always was made abslute to ...file://..
but that problem seems to be solved (and i can not remember the bug-no.
It's a FEATURE not a BUG :P

I read about a workaround somwhere (can't find the bug# either).
Solution was to go into File->Preferences->Composer and deselect "Use CSS styles
instead of HTML elements and attributes".

FEATURE REQUEST:
You know, it would be nice to have a feature which would set all image URL's "by
default" to be relative. It is a big hassle to go in and click the image object,
click "URL is relative to page location", and click OK repetitively.
This isn't a workaround though. This disables CSS. This doesn't fix the bug at
all, which is clearly an issue with "style element background-image", as described.

That's like saying the solution to a problem with the IMG tag would be to
disable images. ;)

I've duplicated this in 20030130/Trunk, under XP. Marking it as such. (Why don't
we have a "Windows: All" OS??)
Keywords: clean-report
OS: Windows 98 → Windows XP
This not just a Windows bug. In Linux, "URL is relative" has no effect when
adding a page background.
-> All OS.
OS: Windows XP → All
*** Bug 195900 has been marked as a duplicate of this bug. ***
*** Bug 198172 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (X11; U; OpenVMS Digital_Personal_WorkStation_; en-US; rv:1.3)
Gecko/20030313
The same thing happens with 'normal' HTML editing as well. The popup window for
the image properties will give us the choice between a absolute or a relative
link, but the result is allways a absolute link.

Workaround: I use a normal text editor to edit the HTML file and change the link
:-)  
problem is, this isn't really a workaround - try doing this for a site with 200+
HTML pages. :)

The biggest problem I see with this bug is, even if you do not edit the
background directly, simply loading then saving a page in composer will result
in this bug if your settings are set as above. This will give the impression
that composer "breaks" webpages.
Flags: blocking1.4a?
Keywords: css1
Flags: blocking1.4a? → blocking1.4a-
Bad bug. It's on Linux, 1.3, as well. And no *feature* !
I tried to disable style-sheets as 'work-around', but still doesn't work. You
have to throw out the Inline-styles with Advanced Edit before it clears out the
remnents of the sheets which supersede the new entries for background.
And absolute addressing is no workaround either, because this is not what I want
and then I'll have to change all over again.
If you have a permanent connection, one workaround may be, insert absolute link
to pubblished image:
<body background-image:
url(http://spazioinwind.libero.it/astrofilimilano/images/sfondo2.jpg);">
In every case this bug is very bad.
Please note:  

1. The copy/paste problem mentioned in Comment #5 is covered by Bug 32768 that's
over 3 years old.  

2. Changing preferences "Retain original source formatting" or unchecking "Use
CSS styles instead of HTML elements and attributes" have no effect on this problem

3. For adding a background image to a TABLE CELL, style="background-image:
url(pic.jpg)" is the only way I can find to comply with the HTML 4.01
Transitional standard without errors in Validation.  However,
background="pic.jpg" seems to work but generates an error in validator.w3.org. 

4. All that's necessary to see this bug is to switch to HTML Source mode and
then back to Normal mode in Composer.  The url is instantly made absolute on the
local drive. Saving the file has nothing to do with it.
All that's happening is that the style system only stores absolute URLs in the
data structs.

iirc, the persistence object has some code to relative-ify those; not sure
whether adam's current work on persisting out backgrounds affects this bug....
My work suffers from the same problem - you stick a relative link into the style
engine and it comes out absolute. It makes it impossible to save files to disk
(or upload them) and then move them around. 

I would much rather the style held the rule as specified and fixed it up for
itself when the need arose, or at least persisted itself using the relativized
version of urls instead of absolute ones.
That could be a pretty severe penalty in terms of memory and/or performance...
Every single style resolution for the element in question would need to convert
URL strings to absolute URIs, or we would need to store both the relative and
the absolute URI in the data struct.
*** Bug 205309 has been marked as a duplicate of this bug. ***
-->glazman since this isn't a persist-specific problem
Assignee: brade → glazman
Depends on: 115107
Keywords: nsbeta1
Hardware: PC → All
>That could be a pretty severe penalty in terms of memory and/or performance...
>Every single style resolution for the element in question would need to convert
>URL strings to absolute URIs, or we would need to store both the relative and
>the absolute URI in the data struct.

This is a severe bug, Boris. I just don't mind if the Style Engine introduced
this to get better perf (and that's the case) or not. It means that any page
having a url() notation in a style attribute cannot be edited using Composer
or Midas. This is clearly a must-fix. From my perspective (and Kathy's), we
should always try to relativize url() notations when the caller is a style 
attribute output.

Cc:ing David Baron. David, what do you think? This is a complete blocker for
Composer.
sorry for spam, I forgot to really cc dbaron for last comment.
The problem could be mitigated somewhat if the stream converter made links
relative as they were streamed out. Then it wouldn't matter so much if they were
absolute internally or not.
Relativizing links as they are streamed out is fine IF the original text of the 
file used relative links.  The problem with this bug, as with several other 
DOM-to-text bugs, is that the original text of style attributes is not being 
maintained; the effects of this particular bug are more serious than most.

Adding this to the dependency list for the meta bug 
   "Composer's 'retain format' preference, doesn't"
Blocks: 174361
My opinion is that Composer with this bug is so bad, that I can switch back to
another visual editor.
I need to manualy edit every html with another editor, just before upload the file!
Please please please (must) fix it, it must be blocking.

Not really understanding how the style system really works (I would love to
learn, but there's lots of code):

Why can't just store it as
* an absolute URI (like we do now, according to comment 18)
 and
* a relative/absolute flag so that when the output is streamed it can be output
in the correct form

(Note that bug 113173 is planned, and might affect how you'd want to fix this bug.)
Depends on: 113173
For those of you threatening to switch editors until this is fixed, there *IS* a
perfectly legal workaround for this bug.  Only took me 30 minutes to fix on a
20-page site.

DEFINE A STYLE for the BODY or the TABLE CELLS, either in your .css file 
STYLESTEET (all you good programmer types *DO* use style sheets, don't you?) or
in the <STYLE> section in the head of the page, thusly:

<style type="text/css">
td.abc {background-image: url(xyz.jpg); }  /* table cell background image */
body {background-image: url(xyz.jpg); }    /* page background image */
</style>

Then use <td class="abc"> for the table cells. And leave the background
reference out of the <body> tag.  If you repeat the same background image in
many places, across many pages, this is MUCH cleaner anyhow.

Also, <TD background="xyz.jpg"> works in every browser I've tested, it just
generates a Validation error because it's not good HTML 4.

If you're not using style sheets, I highly recommend you take a few days and
learn how.  It will improve your page code quality tremendously!  And it's
really easy.  
I too find this bug/feature/whatever very annoying.
adt: nsbeta1+/adt2]
Keywords: nsbeta1nsbeta1+
Whiteboard: [adt2]
Asking for 1.4 blocking due to the recently added nsbeta1+, as well as the sheer
annoyance factor of this bug. To design a web site, and to find it doesn't work
as Composer has changed the path name, isn't overly pleasant.
Flags: blocking1.4?
Putting this up on the radar for 1.4final, since it's still awaiting approval as
a blocker.
Keywords: nsCatFood
Flags: blocking1.4?
*** Bug 214787 has been marked as a duplicate of this bug. ***
This is an issue which first appeared as a glitch with image files in Netscape
Navigator Gold 3.0 PRO edition composer.  It was deemed by Netscape then to be a
known glitch (I spoke with the vice president), and supposed to be corrected by
Communicator version 4.0.  For awhile from version 4.0 until 7.1, uploaded
relative background image links appeared as they were written, e.g., "cat.jpeg".
 Why is Mozilla acting like this arbitrary switching of relative to absolute
file names during the composer "save" function, a new issue?  As far as my
correspondence with Netscape demonstrates, dragged local file assoaciations has
been a problem since at least 1997.  This bug has also been mis-indentified as
bug #216504, fyi.
Flags: blocking1.5b?
Flags: blocking1.5b? → blocking1.5b-
I can't get why is this bug still here. it seems really trivial to fix (replace
the file:// stuff with the relative path as soon as the page can be localized
(either saved or published for the first time) or with not path at all when the
picture is in the same directory as the page). 
Mozilla would be a clean and nice way for my users to update parts of their
site, but this bug would bite them (or more precisely would bite anyone trying
to see their page *except* them) as soon as they add an image and it actually
prevents me from using it since the pages are only properly rendered on the page
creator's own machine.
As Jani Patokallio rightfully stated, this applies not only to background
images, but any images.
I have a related bug. 

I specify:
<head>
  <link rel="stylesheet" href="../Barleystyles.CSS">
</head>

because my stylesheet is stored in the parent directory. During publishing,
composer will convert that to href="Barleystyles.CSS", no matter what. Only way
to circumvent that is to manually edit the html file and upload it with an ftp
client. I think I need an another html editor.. 
Comment 38 is describing an *unrelated* bug, and should be filed in a separate
bug report.
Flags: blocking1.5+
I just use find/replace in a text editor to take out all the file:/// URL stuff.
This, of course, only works well for a small number of pages. Please fix soon
<looks at owner and drivers with Bambi eyes> ...
efa, please don't set flags if you don't know how. Setting to blocking1.5? is
how you nominate a bug.

Glazman, can you summarize what needs to be done to get this fixed?
Flags: blocking1.5+ → blocking1.5-
I'll just repeat what others have said by stating that this makes the Composer
pretty much unusable for a lot of people (not to mention the factor of
embarrassement..).
Flags: blocking1.6a?
Re on #41:
This bug was present in 1.2, and will be present in 1.5 if we dont do it blocking.
Is a dataloss bug, what other we need to block 1.5. I dont want Moz1.5 with this
bug. Everyone must vote for this bug.
I'm really fed up with this bug.

Over time it have been reported countless times under different names, and
despite the fact it really trivial to fix, it's still there nearly two years
after the first report I could find (January 2002, Version 0.9.8 !!!)

Here's what peoples said about it at this time :


http://bugzilla.mozilla.org/show_bug.cgi?id=122227
------- Additional Comment #20 From Peter Meyer 2002-02-09 20:52 -------

Both the original problem and comments #19 show up in Mozilla build 0.9.8 
Please mark this problem as critical.


------- Additional Comment #21 From Mikael Nilsson 2002-02-14 01:03 -------

I use the Editor daily, but this one forced me back to 0.9.7.
I'm glad I use CVS, otherwise I would have lost
*lots* of link info.

This bug must be fixed ASAP.


********************************************************************************

Why is it still there ? What will it take to have it fixed ? How can the
maintainers be so blind not to see that a HTML composer that is unable to
properly add an image to a page is useless, and that having such an embarrassing
bug in Mozilla is simply unacceptable ?

Apart from correcting peoples who (rightfully IMHO) upgrade the bug severity,
after nearly two years of complete unresponsiveness, I'm fed up with this and
fully support comment #42 & #43.

Eric
Flags: blocking1.6a?
Flags: blocking1.6a+
Flags: blocking1.5-
Flags: blocking1.5+
Only drivers are allowed to mark bugs blocking+.
Flags: blocking1.6a?
Flags: blocking1.6a+
Flags: blocking1.5-
Flags: blocking1.5+
Whiteboard: [adt2] → [adt2] Don't comment unless you have a patch.
I perfectly know that I'm breaking the rules doing it, but since all requests
regarding this bug have been systematically ignored for nearly two years, and no
one ever cares to report on the situation or explain why this is not fixed, I
will keep upgrading it until this is fixed or my access is revoked. If you don't
want input from real world users (or choose to systematically ignore it) you
could just as well block access for anyone who is not a coder.

FIX IT !
Flags: blocking1.6a?
Flags: blocking1.6a+
Flags: blocking1.5-
Flags: blocking1.5+
Do you really think that whining will help?
Flags: blocking1.6a?
Flags: blocking1.6a+
Flags: blocking1.5-
Flags: blocking1.5+
Erik, your abusing our system won't be tolerated. It is not reasonable for you
to co-opt reserved fields in Bugzilla to make an advocacy statement. Your
threats of continued abuse make it pretty clear that you're not interested in
playing by our rules so I have disabled your account. Feel free to email me at
asa@mozilla.org if you'd like to argue a case for restoring your account. 
*** Bug 202559 has been marked as a duplicate of this bug. ***
Eric's silliness aside, there are at least 22 people clamoring for a fix to the
bug which hasn't even been marked "CONFIRMED" despite plenty of confirmation and
over one year of discussion...  so it would be nice if this could be, uh, just
fixed.

I'm not about to start delving into the source myself, but how about I send a
packet of cookies or something to the person who checks in a fix to CVS?
I was thinking of making eCSSUnit_URL be, instead of an nsIURI*, a struct
(probably called nsCSSValue::URL) containing an nsIURI* and a char* or
PRUnichar*, but that leads to extra copying during style resolution since we're
using the same nsCSSValue objects for storage and for temporary structures while
walking the rule tree.

It occured to me that we could instead make it a structure containing an
nsCOMPtr<nsIURI> and an nsAutoBufferHandle<char> (or ...<PRUnichar>).  But that
still leaves the problem of duplicating the structure itself during
WalkRuleTree.  An alternative would be making nsCSSValue::URL itself contain the
reference count.  It seems like it shouldn't need to be that complicated, though...
Probably it's better if the nsCSSValue::URL object contains the reference count.
 That's what I'm leaning towards, anyway.
Would an nsSharableCString work? It manages a shared buffer and reference counts
for you. It is 4 words large, however.
Flags: blocking1.6a?
no patch in sight. not going to block the release of 1.6a for this bug.
Flags: blocking1.6a? → blocking1.6a-
Coping the value needs to be fast since it happens a lot during style
resolution, so I think there should be a reference count on the value itself. 
Otherwise we'd need to continually allocate these little objects and copy the
string and the nsCOMPtr.
Referring to it screwing with the background image location:
What am I missing here that is so complicated about fixing this?  Just brute
force the thing from screwing with the code if that check box (URL is relative
to page location) is checked.  Why is this so difficult to fix?  The other
question is why doesn't it get the attention it deserves?  This is a major bug,
anytime a feature that is in software blatantly does NOT work it NEEDS to be
fixed.  Is the fact that it's not being fixed a result of the perception that
many technosnobs have which is that everyone should be coding in notepad
anyway???  The stonewalling on this issue is so inredibly ludicrous.
> What am I missing here that is so complicated about fixing this?

You're missing the fact that this is NOT a bug about something that composer is
doing wrong, but an issue in the way the style system backend handles *all* URL
values.  And that fixing this could have an adverse effect on performance.

> The other question is why doesn't it get the attention it deserves?

The people who are qualified to fix this bug are looking into it and are even
commenting about it in the bug.  But I guess with so many people whining like
yourself, it is getting lost in the shuffle.  And note that the "blocking-"
flags don't mean we don't want to fix it.  Of course we want this bug fixed.  It
just means that the release schedule doesn't come to a complete stop if there is
no fix since there is a workaround (albeit a less-than-desirable one): don't use
CSS editing mode.

And now back to our regularly scheduled programming...
>But I guess with so many people whining like
yourself, it is getting lost in the shuffle.

Typical technosnob response.  If we don't care about it then screw the rest that do.

> don't use
CSS editing mode.<

With all due respect all I am doing is going to 'Format-Page COlors and
Background' and then trying to set a background.  If I deselect the url is
relative blah blah blah it shows just the filename as expected however the
generated source still has the local file url referenced and if you go back into
the dialog it has infuriatingly added it there as well.  I'm not using any 'css
mode' I'm just using composer as I have been since netscape Gold and it never
used to do this.  It sounds like your system underneath is ridiculously overly
complicated for what it needs to do.  Composer is NOT and never has been a
sophisticated html editor but it gets the job done pretty well.  You talk about
CSS etc, if it really had support for this then you could drag items around the
screen with pixel placement resolution and build graphical sites with it like in
NetObjects Fusion.  So the point is the whole thing if it is indeed as complex
underneath as you say,, is COMPLETELY over engineered for what it really does.
Attached patch p (obsolete) — Splinter Review
A Workaround:
Use a text editor that is able to search and replace within multiple documents
like notetab (there is even a free version available) 
Load all html documents, then search for 'file:' and replace all the unwanted
absolute references with relative ones.
This can be done within minutes even for major site updates
I maintain sites with hundereds of html pages and this workaround has enabled to
still use the mozilla composer as my main html editor. 

Still hope the bug will be fixed rather soon. 
Dan Cox (comment 58): you may want to try this:
 Go to Preferences for "Composer"
 Uncheck the bottom checkbox "Use CSS styles instead of HTML ..."
 Click OK
 Open your document in Composer
 Change the background image
 Click OK
 View HTML Source or Save & Open in another application

I would hope that would fix it for you but it's possible you need a few
additional steps to fix your existing files.

Others:  Can someone(s) test dbaron's patch to see if it fixes the problem you
see?  I would expect it would but more testing (especially on various
platforms/OS) can be helpful.  :-)
dbaron: hm... where do you free the mString member of the URL struct?
Attached patch patch (obsolete) — Splinter Review
don't forget to free mString
Attachment #133895 - Attachment is obsolete: true
Attached patch patch (obsolete) — Splinter Review
Attachment #133954 - Attachment is obsolete: true
Attachment #133963 - Flags: superreview?(bzbarsky)
Attachment #133963 - Flags: review?(bzbarsky)
Comment on attachment 133963 [details] [diff] [review]
patch

>+  struct URL {

Add contructor and destructor counters here so we can catch when it leaks?

>Index: content/src/nsGenericHTMLElement.cpp

>+                nsCSSValue::URL *url = new nsCSSValue::URL(uri, spec.get());
>+                if (url)
>+                  aData->mColorData->mBackImage.SetURLValue(url);

What if (url && !url.mString)?	If we want mString to be non-null, we should
null-check it here; if we don't care, why are we bothering with the string
copy?

r+sr=bzbarsky with those nits picked.
Attachment #133963 - Flags: superreview?(bzbarsky)
Attachment #133963 - Flags: superreview+
Attachment #133963 - Flags: review?(bzbarsky)
Attachment #133963 - Flags: review+
Comment on attachment 134185 [details] [diff] [review]
patch addressing review comments

Yeah, that looks great.
Attachment #134185 - Flags: superreview+
Attachment #134185 - Flags: review+
taking
Assignee: daniel → dbaron
Priority: -- → P1
Whiteboard: [adt2] Don't comment unless you have a patch. → [patch][adt2] Don't comment unless you have a patch.
Target Milestone: --- → mozilla1.6beta
Checking attachment 134185 [details] [diff] [review] in led to an increase in codesize.  I think this
rearrangement of the inlining in nsCSSValue should get that loss, and more,
back.
Comment on attachment 134456 [details] [diff] [review]
rearrange inlining to fix codesize penalty

r=bryner
Attachment #134456 - Flags: review+
Comment on attachment 134456 [details] [diff] [review]
rearrange inlining to fix codesize penalty

Zdiff:-40432 (+2626/-43058) on comet, but backed out because of inspector
bustage on many platforms.
Could we un-inline Reset() instead?
Reset only has a handful of callers.  I'd rather go with this patch and fix
inspector to use different APIs.
Fix checked in to trunk, 2003-10-29 17:45 -0800 with bustage fix 19:34 -0800.

Spun off codesize increase into bug 224165, which depends on inspector changes
in bug 224164.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
*** Bug 229959 has been marked as a duplicate of this bug. ***
I just wanted to let you guys know that you may want to rehearse some lame excuses as to why bugs that make Composer useless have continued to go unfixed for ages. You might also want to rehearse why you keep giving the nod to new releases of Mozilla instead of holding them up while glaring old flaws in Composer remain unfixed for well over a year, some two.

After tracing through the relative url problems that have so plagued Composer, making it useless and the apathy towards the many people that have dared to complain about it and your failure to give those crippling problems any of your attentions I thought it might be good to send copies of the sad bug reports & comments on this issue to places such as ZDNet, CNET.com, TheRegister and other sites and services that have reviewed and report on Mozilla in the past. I'm sure most of them find this relative url Composer issue and the comments report-worthy. 

Hey, will you fix these errors now? Gosh that'd be so neat. Times kinda important now... psst... might want to increase the severity status of these errors now ya think?

Can ya see the headlines?

Mozilla Team Passes Useless Composer in New Release - Cnet.com
Mozilla Team Takes Page From Microsoft - Continues to Release Flawed Software
Mozilla Composer Useless - Has Been for Ages Due to Years Long Bugs
Mozilla Team Brags About Whining Users that Want Flaws Fixed

So should I hit send? Or will you now fix the errors w/Composer you knew all about and didn't care to fix now. I'll send it all out to those sites in a few weeks, that should give you more than a fair chance to stop releasing a crippled product in any more future Mozilla releases.

Believe it or not other than this issue, I think you guys are good but really you seem so apathetic on this continuing problem, maybe you need to understand how severe and inexcusable and how bad this all looks. 
This bug was fixed five months ago.
I assume comment 76 was an early "April Fool's joke" and not a serious threat. 
This bug wouldn't be the right place for a threat since this bug is fixed in
recent versions.
I don't know if it's an April fool, but when it comes to this bug, April Fool
have been going on for years, and I'm just as frustrated as the author of
comment #76 about it ...

Yes, I have bad news for the authors of Comment #77 and Comment #78 : the bug is
still there, as 5 minutes of testing would have shown ...

Here are the exact steps to reproduce it :

- Insert an image in composer
- cut it
- paste it somewhere else
- look at the picture's URL 

Voilà !   

file:/// is back in the url !


This have been going on for so long that there must be another explanation ...
let's try some :

- The bug was first evoqued on march 21, 2000 and had the number 32768 (
http://bugzilla.mozilla.org/show_bug.cgi?id=32768 ) , the magical HEX 0x8000. 
Was it secretely decided that bug 0x8000, no matter how serious would never be
fixed ? If so, maybe we're lucky it was not a "Mozilla hangs during startup"
kind of bug ...

- Graphics are for windoze lamers and IE loOOozers ! Real technoSnobs never
could see th bug, since they either do "images" using CSS tricks or, sometimes,
fall for the ancient, but still highly regarded practice of ASCII Art ...
http://www.ludd.luth.se/~vk/q/ada/aaafaq.htm


- It's not a bug, it's a feature : After all, during edition, the images are
local, aren't they ? so ... that's it !

-------------------------------------

Seriously, and without entering in the arcane stuff that seems incredibly
overcomplicated for what it does, would it really be *that difficult* to parse
the file before it's saved/published and resolve with a relative path all urls
that start with file:/// ? Yeah, I know, that's a quickfix, but after 4 years
waiting for the "real thing", anything would do ... 


now call me silly and behaving against the rules, and ban me again ;-)

Eric.

BTW, I would have loved to reopen that bug ... 
(In reply to comment #79)
> - Insert an image in composer

This bug is about background-image styles in your HTML being corrupted by
composer.  That has nothing to do with <img> tags.  Feel free to file a new bug
on this issue if you feel it's a bug and there isn't a bug on it already, but
IT'S NOT THIS BUG.  Now please stop insulting David by claiming he didn't test
his patch, ok?
It is already filed -- bug 32768.  And the author of comment 79 clearly knows
that, but is just spamming the wrong bug anyway.
Thanks to both poster #80 & #81 for their insightful answers !

It's the same bug, may it apply to page background / table background / links or
inline images, the fix made here solved one of the symptoms, but not the reason
behind it.

filling another bug about this "relative path transformed into absolute local
path" problem ? why ? 

The latest that was filled ( bug 237497 ) is less than 2 weeks old and it's fate
was no better than bug 72583 / bug 185057 / bug 190137 / bug 198951 / bug 215264
/ bug 215034 / bug 216504 / bug 218571 / bug 226930 / bug 228199 and bug 237258
... they were all counted as resolved duplicates of still assigned but not
resolved bug 32768 filled in March 2000 !

Do you really want me to post my own flavor of duplicate ? Do you want all the
peoples who follow that bug to post their own duplicate ?

At least here, something was tried to partially fix a symptom (I never insulted
anyone named David, did I ?) and, since all attempts to properly submit the bug
that have been tried during the last 4 years have been discarded as dups of bug
32768, it seems an appropriate place to do so. 

How can a bug that's so obvious to users be ignored with so much perseverence
and for such a long time is clearly beyond me ...

For 4 years, countless peoples have been complaining about the problem,
explaining any way they possibly could that it should be fixed, filling bugs and
at the end of it all : a partial fix for one of the symptom. 
That's where we are ...

So what's next ? 4 more years ignoring the problem ?

Eric.
(In reply to comment #82)
> the fix made here solved one of the symptoms, but not the reason
> behind it.

Wrong, as you can easily tell by reading the patches in this bug and in bug 32768.

The reason for THIS bug was that the CSS parser was discarding the original URI,
hence editor could not recover it.

The reason for bug 32768 is that the copy/paste code discards the original URI,
hence editor cannot recover it.

How are those related?  They have absolutely nothing to do with each other. 
"similar problem" does not mean same bug.  Same problem in the code means same bug.

> filling another bug about this "relative path transformed into absolute local
> path" problem ? why ? 

Because in Mozilla there is typically one bug per distinct problem, and the two
problems involved are distinct problems (being problems in very different parts
of the browser).  But there already exists a bug for the image problem, as David
pointed out.  So what exactly are you trying to say?

> At least here, something was tried to partially fix a symptom

Wrong.  What was fixed here is a bug related to all uses of uris in style data
anywhere in the browser.  In particular in editor.

> (I never insulted anyone named David, did I ?)

Claiming that a patch was not tested would generally be an insult to any
competent patch author (since being competent involves testing the patch).

> 32768, it seems an appropriate place to do so. 

This isn't bug 32768.  Now is it?

> So what's next ? 4 more years ignoring the problem ?

Have you even read bug 32768?  It's far from being ignored.
Eric--if bug 32768 is not fixed for you, please comment there (not here).  As
Boris says, If you were following that bug you'd have noticed that I posted some
patches and that they landed.  I haven't resolved the bug yet because I've been
watching for regressions and waiting for people to comment.  Due to the lack of
activity on that bug lately (besides my patches) I assumed no one cared about it
anymore.  Please read and respond to my latest comment in bug 32768 if you see
the bug.

Lastly, *please* no more comments here unless you are talking about relative
links in css / stylesheets!
Sorry for using french here, I am just fed up with the lurker from Québec:

  ERIC: je suis le Module Owner de Composer et j'en ai **RAS-LE-BOL** de lire
  vos messages plus qu'insultants pour notre travail. Ce bug est RÉSOLU, FERMÉ
  et VÉRIFIÉ.

  Vous avez besoin de la résolution du bug 32768 en urgence ? Et bien prenez-
  vous en charge ET CODEZ-LA CETTE SOLUTION! Allez, hop, au travail, voyons
  ce que vous savez faire. En attendant, ces commentaires n'ont RIEN A FAIRE
  ici, point que j'espère final.

  Pour la suite, soit vous adoptez une démarche plus constructive et arrêtez de
  spammer des bugs résolus pour le simple plaisir de vous défouler, soit vous
  perdrez votre compte Bugzilla.

  J'espère me faire bien comprendre car il n'y aura pas de nouvel avertissement.
  Inutile de répondre, je considérerai toute réponse ici dans ce bug comme du
  spam, et agirai en conséquence. A bon lecteur...
*** Bug 242064 has been marked as a duplicate of this bug. ***
*** Bug 212174 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
*** Bug 137612 has been marked as a duplicate of this bug. ***
*** Bug 302129 has been marked as a duplicate of this bug. ***
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.