Closed Bug 47277 Opened 24 years ago Closed 24 years ago

M16,M17 missing css components (ie gif file) stops window displaying

Categories

(Core :: XUL, defect, P3)

Product:
Core
Component:
XUL
Platform:
x86
Windows 2000
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: simon.lucy, Assigned: hyatt)

References

Details

If the css for a window (such as a dialog) is missing at the time of creation 
then the window is created and event loop is started but no window content is 
displayed, not even the frame.  If the window is modal then all the user will 
get is a beep on the parent window.

If a necessary gif file is missing then the broken image gif (or some suitably 
resized version of it), should be used in its place, or alternatively a non-
graphic warning message box put up with the missing file.

I found this because I tried to use a standard dialog from my completely non-
standard UI, one gif file was missing (return.gif).
Could you please attach a testcase so someone can confirm this?
Its simple enough.  Rename return*.gif in the global/skin directory of the 
current theme, select File/Open Web Location and the dialog will be built but 
not displayed.
For more fun, just rename/delete one of the core images used on the main window.
Result? Mozilla appears to hang instead of loading.
Well then, don't do that.  There are an infinite number of bugs you could file
about our behavior when launched in a corrupted environment.  They are valid,
but we don't have time to fix them in this release.  ->future
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → Future
Sorry.  That's not good enough.  This behaviour cost me a lot of time.  M16 
tarball when built appears to hang because menu.css isn't copied to the 
Communicator skins directory.  This is not a frivolous report. Take it 
seriously.  The real problem is that the whole deck of cards is fragile, the 
lack of error recovery at this stage is more than worrying it is likely to be 
fatal to any actual product when its shipped.
Target Milestone: Future → M18
Well then, it isn't good enough. Too bad, but we don't have time to make it any
better in this release.  And I'm not being frivolous, I take triage very
seriously, since I'm responsible for a team of engineers delivering on our
committments. We will not commit to doing any such work in this release.
->future.
Target Milestone: M18 → Future
Assigning it as future is like throwing it away.  If you want to do that then 
fine.  You may be responsible for your engineers, I'm responsible for my 
product also which depends on this.  If you're applying commercial criteria 
then I'd think seriously about NSBETA at least.  I'm not even reporting this as 
an overall problem but as a specific problem relating to missing images and UI 
windows, and suggesting a solution.  Hell, the least that could be done is 
emitting a printf saying 'xxxxxx.xxx' was missing.  If I squirrel out where in 
the code the file open fails I'll make a patch and attach it.

So if you aren't interested in scheduling it, assign it to me and have done 
with it.



Does the mozilla executable have a built-in routine for generating a native error 
alert with arbitrary text? That would provide the means for fixing this bug (and 
explaining to the user what has happened when bug 42198 and similar bugs occur). 
printf-ing isn't going to cut it if you haven't got a console to do the
printf-ing to.

There's NS_ERROR(), I admit my minimalist solution wasn't user friendly :-)
Targeting future is _not_ throwing it away, merely facing the hard reality that
to ship any product based on this code we have to severely constrain the changes
that we commit to from here on out.  If you've ever shipped software on schedule
 then you know that every project must go into a date-driven 'ship mode', and
many hard decisions have to be made about what is allowed to change. This class
of defect is only likely to happen to developers, or people who deliberately
alter the program installation. We don't have time to handle all such problems
(and there are many); although if you want to attach a patch, it could still be
considered.
Yes, I have been responsible for products that have shipped on time and yes I'm 
well aware of the hard decisions that have to be made.  A class of those 
decisions though relate to stability and shipping a product on time that is 
unstable does no one any good.
For a while I'd have accepted that this was a developer only issue, a few 
things changed my mind about that (and no fruitless hours searching for a 
missing gif file wasn't one of them).  

Firstly, since skins became switchable users have the ability to install skins 
that may be incomplete or may remove or not include gif files that are 
required.  There isn't very much the user can do about this unless they are 
given an indication as to what is missing.  Now, you can pass on the 
responsiblity for that but that won't wash in the long run because so far as 
the user is concerned its broken.

Secondly, M16 tarball was broken as shipped.  Granted a little more QA might 
happen on a product release but given Murphy, time constraints et al, its just 
possible that the classic UI (for instance) doesn't happen to get checked until 
after release.  Again you can just issue a file or instructions and some people 
will get on with it, quite a lot won't though and its another software 
corollary of Murphy that bad builds hang around like blocked drains in the 
summer.

Thirdly, and from my point of view, the most important reason is that this kind 
of graceful error recovery should be built in from the start and not bolted on 
as an afterthought.  In saying this I'm well aware of the gnarly twists one can 
get in trying to recover from an error nested down in the undergrowth.  
However, in looking around the chrome registry code, as an example, I have to 
say that its not exactly written defensively, I'm not even an extreme purist 
about having single return points from functions but the number of returns from 
some of the important functions is quite alarming.  No one is going to be able 
to run something like McCabe on this and say hand on heart that there's 90% 
code coverage from the testplan, nor is anyone likely to be able to write a 
testplan to achieve it.

Thanks for the gracious possibility of accepting a patch if I make one.

We are trying to ensure that our product, as shipped, is stable. I agree with 
much of what you say, but that still doesn't change the fact that we don't have 
time to ensure that we will gracefully handle damage done to our installed 
product by third parties, or by defective third-party skins.

#1 is a good argument for users to be careful to only install skins that have 
been tested by someone they trust.  I don't like having to say that, but the 
only alternative in this release is to remove themes entirely.
#2 is talking about a checkpoint tarball, not a product that has passed final 
testing by Netscape QA.  There is a significant difference. Caveat Tester!
#3 is painfully true, more than you know, but that is what we have and must 
ship.  We don't have a rigorous test plan, no automated testing, and I don't 
think we have any idea of our code-level coverage. Any help in this regard 
would be appreciated.

->hyatt, untargetted. We should try to add some error-checking for xpfe
developers in this release.
Assignee: trudelle → hyatt
Status: ASSIGNED → NEW
Target Milestone: Future → ---
resolving as fixed per hyatt.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
*** Bug 40641 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.