266807 - Regression: Images not displayed in composer window

Status: RESOLVED WORKSFORME

(SeaMonkey :: Composer, defect)

Description

[Nelson Bolyard (seldom reads bugmail)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a4) Gecko/20040927
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a4) Gecko/20040927

I do a bunch of simple web page composing with mozilla.  
I recently switched from 1.7 RTM to 1.8a4, and numerous regressions
are apparent.  

I create a simple web page.  Using "Insert" -> "Image", I insert a 
jpg file (640x480) into the page.  When I click the OK button to 
finish the image properties dialog, a border appears of the proper
size, but the image does not appear in the space occupied by the 
border.  

Worked ok in moz 1.7, but is not working in 1.8a4.  

I typically put 10 images or more in a page.  Sometimes the first image
or two displays OK (usually not), but always by the time I've inserted
the 3rd or 4th image, that image and the ones that follow all show up
as borders with no image shown in the border.


Reproducible: Always
Steps to Reproduce:
1. Compose page with one or more images, using a URL relative to page location.


Actual Results:  
See border, but no image, in the composer main window.

Expected Results:  
Should see the image in the composer window.

Again, this seemed to work OK in 1.7 RTM, but not in 1.8a4

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

1.8 is on the trunk, right?

BTW, this system has oceans of RAM, and mozilla's VM size isn't particularly
large, so I don't think these composer image problems are due to an 
out-of-memory condition.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

Here is a workaround that sometimes, but not always, causes the images 
to be displayed in the composer window.  After saving the composed 
document locally, close it, and then reopen the page in the composer.
This will often cause the images to be displayed in the composer windows.

Also, it should be noted that the "browse" button, which displays the 
local copy of the page in an ordinary browser window, always shows the 
images correctly.  It is only in the composer window that they do not 
appear normally.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

Requesting this block 1.8a5, since it is a regression.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Attachment: snapshot of composer window with empty image

This is what I typically see in the composer now, after adding an 
image in a newly composed page.

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

See this page at http://selenab.home.comcast.net/letter7/testpage.html

Comment 6

[Tracy Walker [:tracy]]

I can't reproduce this with recent 1.8a5 trunk builds on Windows XP. I've tried
.gif's and .jpg's; opened several images in various manners.  All images always
display correctly.

Comment 7

[Philip K. Warren]

For me to reproduce this, I had to create a page in composer, save it, and 
then insert the images using relative links.

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

Re: comment 7
Right, composer won't let you use relative links until you have saved the
page.  SO, you have to create a new page (it can be empty), save it, add
the images to it.  The problem persists until you close the composer window
and reopen the page in a new composer window.  Then the images that were 
already in the page will appear, but any new images that you add to the page
after that will not display until you again save, close and reopen the page 
in the composer.  It should not be necessary to close and reopen the page to
see the images with the relative links.

Comment 9

[Asa Dotzler [:asa]]

Not going to hold the alpha for these but it would be good to get a regression
window so we can figure out what broke this and fix it before we get to beta.

I still can't reproduce this. Can someone please put very specific minimal steps
to reproduce this? 

Comment 10

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 11

[Nelson Bolyard (seldom reads bugmail)]

This was a problem for a long time, but it seems to be working OK now.