Closed Bug 167262 Opened 22 years ago Closed 21 years ago

style element background-image: composer makes relative links absolute

Categories

(SeaMonkey :: Composer, defect, P1)

Product:
SeaMonkey
Component:
Composer
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
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)

patch addressing review comments
16.79 KB, patch
bzbarsky
: review+
bzbarsky
: superreview+
Details | Diff | Splinter Review
rearrange inlining to fix codesize penalty
11.14 KB, patch
bryner
: review+
Details | Diff | Splinter Review
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: nsbeta1 → nsbeta1+
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.
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: 21 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.

Attachment

General

Creator:
Created:
Updated:
Size: