Closed Bug 43200 Opened 24 years ago Closed 24 years ago

Items don't display until page refresh occurs

Categories

(SeaMonkey :: UI Design, defect, P3)

Product:
SeaMonkey
Component:
UI Design
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: morse, Assigned: hyatt)

References

Details

(Keywords: regression, Whiteboard: [nsbeta2-])

Attachments

(1 file)

patch to WalletEditor.xul; use <box> instead of <html>
2.88 KB, patch
Details | Diff | Splinter Review 
Following Hyatt's carpool of June 19, many items no longer display when dialogs 
are initially brought up.  If you covering the dialog with another window and 
then uncover it, the missing items appear.  This indicates that it is a refresh 
problem.

Examples of where this is occuring are:

Cookie list in cookie viewer
Cookie site list in cookie viewer
image list in cookie viewer
signon list in signon viewer
signon site list in signon viewer
forms-not-previewed list in signon viewer
forms-not prefilled list in signon viewer
text at top of wallet preview window
tree headings in wallet preview window

Besides the initial state of the dialog requiring a forced refresh, you also 
need to do a forced refresh whenever you take some action that should cause the 
dialog display to change.  Examples are

pressing remove-all in any of the three tab displays of the cookie viewer
pressing of remove-all in any of the four tab displays of the signon viewer
adding of items using any of the add buttons in wallet editor
 
(Note: This bug has been broken off of bug 43126 as requested.)
Blocks: 43126
Keywords: nsbeta2, regression
QA Contact: sairuh → jrgm
Putting on [nsbeta2+] radar for beta2 fix.
Whiteboard: [nsbeta2+]
Removed <div>s or changed them to <html> per hyatt's suggestion.  This fixed the 
problem in all the instances sited above except for the following:

  - adding of items using any of the add buttons in wallet editor

Furthermore, here's an example that I forget to mention previously.  It also 
requires a forced refresh before the values are displayed, and removing the 
<div>s did not fix it.

  - wallet editor, select any field, you should see its value.
Target Milestone: --- → M18
steve, could this be a dupe of 44141 now?

It could be a dup of 44141.  However I originally thought that all the examples 
cited at the beginning of this bug report were dups of each other (hence a 
single bug report).  But that turned out not to be the case -- removing the 
<div>s fixed some but not all of them.  So I'd be reluctant to have this marked 
as a dup of 44141 just yet.  If it turns out that one fix solves both problems, 
then we'll know for sure.  But of course then we won't care as we'll just mark 
both of them fixed.

*** This bug has been marked as a duplicate of 43224 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Well this obviously wasn't a dup of 43224 after all.  That bug has just been 
resolved as fixed but with a tree that I just pulled I am still seeing the 
symptoms reported here (as ammended in my comment of 6-22).
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Can you get the tree out of the <html> tags?  They shouldn't be inside <html> 
blocks.  You're basically going from XUL layout into HTML layout and then back 
into XUL layout when you do this.  This slows your dialogs down and is probably 
how you're exposing the bug in trees.

If I remove the <html> tags, then the repaint problem vanishes.  But then my 
layout is wrong.  I need to have one tree on the left and then two trees (one on 
top of the other) on the right.  I was initially doing this with <div> but 
changed them to <html> as per your suggestion.

The file involved is extensions/wallet/editor/WalletEditor.xul.  Can you look 
at it and tell me how to change it so as not to use the <html> tags.  To display 
it, select the menu item tasks->privacy->form-manager->view.  Thanks. 
Sure.  I think this is better as a short-term fix, since it will let me move 
this repaint bug off to beta3.

See if that patch meets your needs. It mainly replaces <html> with an oriented 
<box>. (It also removes a spring that seemed redundant, but maybe I'm wrong; 
and it changes <html:script> to <script>, although that's largely a moot 
change.)
John, thanks, that works great.  It does everything I need and it doesn't have 
the repaint problem.  I'll check it in.

One question -- you use align="vertical" in one place and then orient="vertical" 
in another.  What's the difference and should we be consistent?
align is deprecated.  use orient.

Once you check in, post here, Steve.  Thanks.
Status: REOPENED → ASSIGNED
Thanks for the patch, jrgm!

You can also use <vbox> and <hbox> to get vertical and horizontal <box> without
typing 'orient="..."'. However, this 'hard codes' the orientation, so if you
wanted a skin to be able to modify the box orientation, you would be better to 
use 'orient="..."'. (But for most dialogs, only one orientation makes sense).
Fix checked in.  I'm remove the nsbeta2+ designation now.  But you probably want 
to keep the bug report open because we've only sidestepped the problem in the 
wallet editor rather than fix the underlying problem.
Whiteboard: [nsbeta2+]
I agree.  Thanks guys.  You're making my life easier. :)

Putting on [nsbeta2-] radar. Not critical to beta2.
Whiteboard: [nsbeta2-]
The problem with the wallet editor has just resurfaced.  It was working fine 
with a tree pulled on the morning of July 25.  But with a tree pulled on the 
afternoon of July 28th it isn't working.

To summarize, the following steps illustrate the problem:

1. Put an item into the stored wallet data.  You can do this as follows:

   tasks->privacy->forms-manager->demo
   click on any of the demo pages listed
   fill in any field on page
   tasks->privacy->forms-manager->capture

2. View the stored wallet data

   tasks->privacy->forms-manager->view

3. Click on the name of the field in the table on the left

4. Value for field should appear in upper table on the right.  It doesn't.  
However, after a forced redraw (such as by covering and then uncovering the 
dialog with another window) the value appears.

This was fixed by using John Morrison's work-around (described above) of 
removing the html tags from the WalletEditor.xul file.  But with the latest 
tree, even without the html tags we again have the problem.
With the wallet-editor symptom reoccuring, this bug is serious once again.  The 
nsbeta2+ designation was removed when the wallet editor symptom was 
worked-around.  So now that that symptom is back, I feel justified in marking 
this as nsbeta3+.
Keywords: nsbeta3
Whiteboard: [nsbeta2-] → [nsbeta2-] [nsbeta3+]
*** Bug 47220 has been marked as a duplicate of this bug. ***
removing nsbeta3+ for real triage.  Steve, you are not justified in plussing
other people's bugs. Only manager/PM pairs are supposed to do that, and then
only for bugs their teams own.
Whiteboard: [nsbeta2-] [nsbeta3+] → [nsbeta2-]
So, this works now on win2k(classic/modern) and mac(modern), but does not 
initially display on linux (classic/modern) and mac(classic) until either
a paint is forced (hide/reveal window) or you leave the first field and 
then return to it again. 

I expect that the core bug is bug 48459 for which there is a simple testcase, 
and is a nsbeta3+ bug at this time. (I knew there was another bug somewhere
with this behaviour but couldn't find it last night).
Depends on: 48459
So, now that bug 48459 is fixed, is this fixed too, or was that just a dependency?
Yes, hyatt's fix for 48459 fixed this as well.  Marking as fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: