User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6a) Gecko/20031030 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6a) Gecko/20031030 When making a web page and inserting image files, even when the images are in the current directory, the path is listed as "file:///F:/jpg/storage/xxx.jpg". If you delete "file:///F:/jpg/storage/", then then image does not appear, only a blank box of the correct size. So, if you want to see the image while composing, you have to edit the html output file before posting to the web to eliminate all that path ****. Funny that you have to insert the line "file:///" into the mail notification play file window, but you have to delete it in composer... Reproducible: Always Steps to Reproduce: 1. 2. 3.
15 years ago
The path of the image file has to be relative to an html file which has been saved to begin with. If the html file has not been saved yet (while editing the document), then a filename.ext is relative to nothing really. The important question here is if the noted behavior happens when the html document has been saved on the hard-disk. Once the html file has been saved locally, then it is possible to insert an image and declare its location as relative to page's location or even change its relative location. I tested this carefully. I think this bug should be resolved as WORKSFORME; at least, I can not reproduce it. Mozilla 1.6beta build 2003121608 on XP Pro SP1 here.
"Tip: It's best to first save or publish your page before you insert images into it. This allows Composer to automatically use relative references to images once you insert them." Coming from Help/Help Contents/Contents tab/Creating Web Page/Adding Images to Your Web Page/Inserting an Image into Your Page
This happens to me about 25% of the time. I've yet to figure out when and where and its gone on since Netscape 4.x... I can say that the files have often been saved before inserting the image... Maybe some day I'll be able to reproduce it, but so far, its just very annoying... especially if I publish the file without first checking to see if the incorrect file:/// path has been inserted (since the image will STILL appear correct when I view it from the web since the path is to MY machine...just nobody else can see it!)
I fogot to add... It changes ALL the image paths, no just the one I'm working on. Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.6) Gecko/20040113
Brad--can you please restate the steps to reproduce the bug you see? Please be clear how you are inserting the images (drag and drop from OS, drag and drop from browser, insert menu, copy/paste from a different composer window, etc.) Also, can you test with a newer build?
Having lived with this for so long, it is slow finding the problem, but I have noticed to consistent areas so far... Cutting and pasting from another composer window appears to cause the problem, though I don't think it is the only place where it happens. I speculated that if my relative path was different that that was contributory, however, I confirmed that the same relative path that the NEW window WOULD have provided is the one that was being used in the OLD composer window. Also I have noticed that a similar problem occurs with links within a document. If you have previously coded a link to be only #linkwithindoc instead of ../subdir/page#linkwithindoc then Composer seems not to understand and replaces the link with the (dreaded) file:///c:/subdir/page#linkwithindoc It would sure be nice if there were an umbrella setting for images and links wherein one could PRESET relative paths as THE choice. I'll keep plugging away and see if I can find other places where this occurs. Annecdotally (ie my memory lapses, but I know it happens), I know it does happen in other instances....
(In reply to comment #6) > Having lived with this for so long, it is slow finding the problem, but I have > noticed to consistent areas so far... > > Cutting and pasting from another composer window appears to cause the problem, > though I don't think it is the only place where it happens. I speculated that > if my relative path was different that that was contributory, however, I > confirmed that the same relative path that the NEW window WOULD have provided is > the one that was being used in the OLD composer window. > As mentioned before, the path of the image file has to be relative to an already saved html file in the first place. The "URL is relative to page location" checkbox becomes enabled (losing its dimmed look) when the page has been saved. "If you have never saved or published the page, you must first save the page in order to enable this [URL is relative to page location] checkbox. (This checkbox is not available if you open the Image Properties dialog box in a message compose window.)" coming from Help/Help Contents/Contents tab/Creating Web Page/Adding Images to Your Web Page/Editing Image Properties/2 (5 also)/URL is relative to page location An author can not enable nor change nor set this "URL is relative to page location" checkbox as long as the html file has not been saved: Composer's behavior here is correct and appropriate. > Also I have noticed that a similar problem occurs with links within a document. Please do not add other comments which may be related to another bug or issue. > It would sure be nice if there were an umbrella setting for images and links > wherein one could PRESET relative paths as THE choice. > For now, that is the author's prerogative, organization task to do. Once you define a directory for your web pages projects and once you actually save for a first time your html page (a first draft), then all elements (like images, links) and their references can be relative to your directory location settings (author-defined). If there is a bugzilla bugfile on this PRESET idea of yours, it would be another bugfile and it would have to be set, created in Edit/Preferences.../Composer/New Page Settings dialog window. For publishing settings, try in Composer: Edit/Publishing Site Settings.../ then enter your site settings, data, info and Set as Default button Brad, you can file other bug reports but please state clear, objective steps to reproduce as factually as you can: that way, others can try to reproduce the problem you see. Try to avoid comments which could or would only be understood by yourself.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → WORKSFORME
> As mentioned before, the path of the image file has to be relative to > an already saved html file in the first place. The "URL is relative to page > location" checkbox becomes enabled (losing its dimmed look) when the page has > been saved. As I'd mentioned earlier on (in another comment, I did not file the initial report), reproducing has been difficult at best but I stated that I know for sure that the pages had been saved multiple times with proper relative paths. > Please do not add other comments which may be related to another bug or issue. You are referring to my mention about links which exhibit the same behavior. My comment was placed there because the type of action appeared to be the same. In other words, perhaps there is something which is searching the code for a particular pattern, or better stated, a way of stating the relative path (which can be varied and still work). This was not a report of a seperate bug (though it may be) but a hope that it would be a clue to what is going on. Upon closer examination, you can see this behavior in the IMG path box. When it contains a file://<etc> path, if you deleted the ":" character, the dimmed box becomes undimmed. Thus it occurred to me that the similar action might be a clue to what is occuring in this bug report. > Brad, you can file other bug reports but please state clear, objective steps > to reproduce as factually as you can: that way, others can try to reproduce > the problem you see. I was confirming the behavior that somebody else had seen. I have not been easily able to ascertain when it occurs because of the different situations in which it does occur. I entered a second commentary that indicated that it occurs when cutting/pasting from another composer window. I can now add another situation: 1. Working from a previously created and saved page with an image with a proper relative path (box is check) 2. Edit the page by cutting and pasting the image to another spot on the page. 3. The relative path returns to the file:///c:/subdir/<etc> problem. Unfortunately, I anecdotally know that this occurs elsewhere and I have been endeavoring to continue to track it and report it when I find it.
You need to log in before you can comment on or make changes to this bug.