Closed Bug 43200 Opened 25 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: 25 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: 25 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: