265416 - Image properties dialog doesn't show image preview

Status: RESOLVED FIXED

(SeaMonkey :: Composer, defect)

Description

[Matti]

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

It flicks in for an instant and then disappears.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Comment 1

[Frank Wein [:mcsmurf]]

Confirming, didn't find a dupe or that this is expected behaviour.

Comment 2

[Frank Wein [:mcsmurf]]

Ths regressed between 2004-09-11(-05) and 2004-09-14(-06).

Comment 3

[Frank Wein [:mcsmurf]]

Bonsai link:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-09-11+05%3A00%3A00&maxdate=2004-09-14+06%3A00%3A00&cvsroot=%2Fcvsroot

Comment 4

[Frank Wein [:mcsmurf]]

New regression time frame (i asked someone to test a linux build, because there
were no windows builds between -11 and -14). It's 2004-09-11(-05) and
2004-09-13(-01).
Bonsai:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-09-11+05%3A00%3A00&maxdate=2004-09-13+01%3A00%3A00&cvsroot=%2Fcvsroot

Comment 5

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

The bug is probably related to the computed width of the description box sitting
above the image itself in the dialog. It should be more or less 50 pixels (I see
51px in Nvu (based on 1.7.1) and old versions of Composer) while I see the real
size of the image in the more recent builds.

Comment 6

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Ok, this is a severe regression in the user-friendlyness of Composer/Nvu and I
think it should be considered as a UI blocker.

Comment 7

[Boris Zbarsky [:bzbarsky]]

What are the steps to reproduce here?  (The ones missing from comment 0.)

I tried loading this page in editor and viewing image properties on the banner
at the top of the page in a 2004-10-24-05 build.  The preview image is shown. 
The only difference between the Sept 11 and Sept 13 build is the vertical
alignment of the image -- in the latter build it's shifted up a bit more.

Comment 8

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

(In reply to comment #7)

> What are the steps to reproduce here?  (The ones missing from comment 0.)
> 
> I tried loading this page in editor and viewing image properties on the banner
> at the top of the page in a 2004-10-24-05 build.  The preview image is shown. 
> The only difference between the Sept 11 and Sept 13 build is the vertical
> alignment of the image -- in the latter build it's shifted up a bit more.

in a 2004-10-21 build, I was immediately able to reproduce the bug:
1. Launch composer
2. click on insert image
3. click on the Browse button to select a local image file 
4. the dialog should show the image preview and does not

Comment 9

[Boris Zbarsky [:bzbarsky]]

Ah, ok.  Sounds like a totally different codepath from the one I was testing...

I'll check this out tonight, I guess.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase, I think.

The green box should more or less shrink-wrap the little image.  It doesn't.

Note that making the little image display:block makes it work.

Also note that messing with display of the hbox or description will make it
work too.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Attachment: Even more minimal

Comment 12

[Boris Zbarsky [:bzbarsky]]

So the testcase shows what seems to be an incremental reflow problem in XUL. 
Basically, reflowing the image reduces the size of the image but does not reduce
the size of the <description> containing the image.

If I remove the max-width and max-height, then reducing the size of the image
doesn't even work (as in,the image is still rendered 200px tall by 400px wide,
in spite of onload setting its width and height).

I'm not sure what suddenly exposed this incremental reflow bug in the editor
case, but here we are.

Again, making the image be a block helps, so editor can use that as a workaround.

I'm attaching a patch that uses the other workaround -- collapsing the image
holder while the image loads and uncollapsing onload, so that reflow happens
correctly....

Comment 13

[Boris Zbarsky [:bzbarsky]]

Attachment: Workaround XUL issue

Comment 14

[Mats Palmgren (inactive)]

Regression window: 2004080605 -- 2004081000,  (bug 230170 looks closest to me)

Comment 15

[[e-mail]]

Comment on attachment 163457 [details] [diff] [review]
Workaround XUL issue

>+    // XXXbz that bug is long-since fixed.  Is this still needed?
You mean, that we should reuse a predefined image? Sure, I additionally tried
patching that and it seems to work fine - and I even discovered a harmless bug
in the code while rewriting it.

Comment 16

[Boris Zbarsky [:bzbarsky]]

Bug 230170 could well have exposed bugs in the reflow code by changing ordering
of things, yes.

> You mean, that we should reuse a predefined image? 

Yep.  I'll file a followup bug to that effect.

Comment 17

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Comment on attachment 163457 [details] [diff] [review]
Workaround XUL issue

r=[e-mail]
Please just add a comment line saying this is a workaround for bug 265416 ; we
should not need this patch.

Comment 18

[Boris Zbarsky [:bzbarsky]]

Filed bug 266284 on the XUL issue and bug 266286 on removing the other
workaround in this code.  Checked in, with the comment Daniel asked for added.

Comment 19

[Boris Zbarsky [:bzbarsky]]

*** Bug 266802 has been marked as a duplicate of this bug. ***