Closed
Bug 101426
Opened 23 years ago
Closed 23 years ago
Inserting an image with a relative link doesn't display after saving a new page to a file
Categories
(SeaMonkey :: Composer, defect)
SeaMonkey
Composer
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9.5
People
(Reporter: sujay, Assigned: cmanske)
Details
(Whiteboard: EDITORBASE)
Attachments
(1 file, 1 obsolete file)
(deleted),
patch
|
cmanske
:
review+
kinmoz
:
superreview+
|
Details | Diff | Splinter Review |
using 9/24 trunk build
1) launch netscape
2) launch composer
3) insert some text
4) give this a title and save to desktop
5) insert an image from desktop into that same file
6) make sure the relative URL checkbox is unchecked
7) click OK
notice the image doesn't appear
to get the image to appear you have to go back into that
image props dialog and check the relative URL checkbox and then click OK
again. then the image appears.
Comment 1•23 years ago
|
||
step 6 should be : make sure the relative URL checkbox is 'checked'
yes make sure it is checked to see the problem...
then uncheck it and you'll see the image again.
Comment 3•23 years ago
|
||
The problem seems to show up when you start on about:blank then save to a file.
If you start already pointing at a file and insert another image from the same
directory, it works fine.
I think the problem is that layout doesn't know that the base url has changed,
so it isn't following the relative link.
Assignee | ||
Comment 5•23 years ago
|
||
Hey! We discussed this thoroughly, I thought! It has nothing to do with the
"Make relative" checkbox! The issues is that inserting an image that is on the
desktop into a file on the desktop doesn't appear. I tested this using 6.1,
which doesn't have the "Make relative checkbox".
Summary: image disappears after toggling relative URL checkbox → Inserting an image from Windows desktop into a file on desktop doesn't display.
Comment 6•23 years ago
|
||
Shri and I reproduced this on linux looking at files in /tmp.
Works fine on reloading the file, just not when you start from a blank document
and then later save to a filename. Or is that covered by a different bug? Shri?
If that is indeed this bug, the summary is misleading.
Comment 7•23 years ago
|
||
Akkana is correct: If you open an existing file from the disk and add an image,
things are ok. It's only when you create a new document then this problem is
seen. Akkana, we do not have another bug for that, pls change the summary to
what you feel is correct. Thx!
Comment 8•23 years ago
|
||
This summary isn't great, but it's closer. Charley can change it if he wishes.
Summary: Inserting an image from Windows desktop into a file on desktop doesn't display. → inserted image (rel. link) doesn't display if file was opened as about:blank
Assignee | ||
Comment 9•23 years ago
|
||
That sounds fine to me! At least it gets to the real problem.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.6
Assignee | ||
Comment 10•23 years ago
|
||
So I've investigated this and it seems that Composer is at fault. We should be
setting the document URL and base URL when the URL for the file changes.
The base URL is used to resolve the full path for loading images.
So I implemented a fix that calls nsIDocument::SetDocumentURL() and that works
fine, but trying to set the base URL using nsIDocument::SetBaseURL() fails
because of a security code check.
Contacting JST for help.
Severity: normal → major
Summary: inserted image (rel. link) doesn't display if file was opened as about:blank → Inserting an image with a relative link doesn't display after saving a new page to a file
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla0.9.6 → mozilla0.9.5
Assignee | ||
Comment 11•23 years ago
|
||
I figured out the problem -- security code is not an issue.
Assignee | ||
Comment 12•23 years ago
|
||
Assignee | ||
Updated•23 years ago
|
Comment 13•23 years ago
|
||
Comment on attachment 50939 [details] [diff] [review]
Set the document and base URL in Composer document. This is the method nsEditorShell::OnLocationChange() called when the file is saved and URL is changed.
sr=kin@netscape.com
With the one NOT_INITIALIZED to FAILURE change we talked about for consistency.
By the way, thanks for testing and assuring me this all works fine during the load process.
Attachment #50939 -
Flags: superreview+
Comment 14•23 years ago
|
||
Comments;
+ nsCOMPtr<nsIScriptGlobalObject> globalObj = do_QueryReferent(mContentWindow, &
rv);
+ if (NS_FAILED(rv) || !globalObj)
+ return NS_ERROR_FAILURE;
+
+ nsCOMPtr<nsIDocShell> docShell;
+ globalObj->GetDocShell(getter_AddRefs(docShell));
+ if (!docShell) return NS_ERROR_FAILURE;
We do this all over; we should factor it into a protected method
("GetDocShellFromWindow").
+ rv = domDoc->GetElementsByTagName(NS_ConvertASCIItoUCS2("base"),
getter_AddRefs(nodeList));
Better to use NS_LITERAL_STRING rather than NS_ConvertASCIItoUCS2().
Otherwise, r=sfraser
Assignee | ||
Updated•23 years ago
|
Attachment #50939 -
Attachment is obsolete: true
Assignee | ||
Comment 15•23 years ago
|
||
Assignee | ||
Comment 16•23 years ago
|
||
Comment on attachment 51312 [details] [diff] [review]
Updated patch: Created "GetDocShellFromContentWindow" as requested by sfraser
r=sfraser
Attachment #51312 -
Flags: review+
Assignee | ||
Updated•23 years ago
|
Whiteboard: FIX IN HAND need r= → FIX IN HAND need sr=
Comment 17•23 years ago
|
||
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.4) Gecko/20011001
Netscape6/6.2
BuildID: 20010928
When creating a new document with an image, if the URL is checked the image does
not show in document, just the image text.
Reproducible: Sometimes
Steps to Reproduce:
1.open composer
2.insert image (I got image form hardrive)
3.Place check mark in URL
4.Click OK
Actual Results: You have the image box with the image text instead of picture.
Expected Results: Picture should be displayed
I noticed that this only happens on new pages not on saved pages.
I also noticed that part of the time the URL box is greyed out- always getting
the image from same location.
Comment 18•23 years ago
|
||
Comment on attachment 51312 [details] [diff] [review]
Updated patch: Created "GetDocShellFromContentWindow" as requested by sfraser
sr=kin@netscape.com
What's this change for?
- eCantEditOther = 3
+ eCantEditFileNotFound = 3,
+ eCantEditOther = 4
Attachment #51312 -
Flags: superreview+
Keywords: review
Whiteboard: FIX IN HAND need sr= → FIX IN HAND, reviewed
Assignee | ||
Comment 19•23 years ago
|
||
Those enum changes are for bug 9475.
Assignee | ||
Comment 20•23 years ago
|
||
Oops, I meant those enums are for bug 93475
Assignee | ||
Comment 21•23 years ago
|
||
checked in
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Keywords: patch
Resolution: --- → FIXED
Whiteboard: FIX IN HAND, reviewed → EDITORBASE
Comment 23•23 years ago
|
||
removing item for this fixed bug from mozilla 0.9.6 release notes
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•