When inserting image files, the resulting html doc has to be edited for correct path

RESOLVED WORKSFORME

Status

SeaMonkey
Composer
RESOLVED WORKSFORME
15 years ago
4 years ago

People

(Reporter: Ed Parker, Unassigned)

Tracking

Trunk
x86
Windows 98

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

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

Comment 1

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.

Comment 2

15 years ago
"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

Comment 3

15 years ago
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!)

Comment 4

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

Comment 5

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

Comment 6

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

Comment 7

14 years ago
(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

Comment 8

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

Product: Browser → Seamonkey

Updated

4 years ago
Whiteboard: DUPEME
You need to log in before you can comment on or make changes to this bug.