Closed Bug 21940 Opened 25 years ago Closed 25 years ago

content of input field doesn't show up after expanding a toolbar

Categories

(Core :: XUL, defect, P2)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: bugzilla, Assigned: eric)

References

Details

(Whiteboard: This is fixed will check in with dirty box landing.)

Attachments

(1 file)

I can reproduce the problem either with the browser URL input field or with the
subject field in message compose.

1) Open a new message
2) Enter something into the subject input field (like "Test")
3) Because of bug 21939, set the focus into the To: field
4) collapse the addressing toolbar
5) Expand back the toolbar
6) --> the subject input field is gray and seems empty
7) Click into the subject input field
8) --> the background is white again and the content is back too

NOTE: in case you miss step 3, you wont be able to activate the subject field
after expanding the toolbar. You need first to select the To: field and then you
can select the subject and see the content be redraw correctly
Blocks: 16841
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
*** This bug has been marked as a duplicate of 17460 ***
Status: RESOLVED → VERIFIED
verified
Status: VERIFIED → REOPENED
by my readings this is not a duplicate of bug 17460. THAT bug says content
of a text field is LOST after collapsing/expanding a toolbar containing the field. THIS
bug says the content is not DISPLAYED until clicking back into the text field. Moreover,
bug 17460 now specifically calls for the creation of a bug dealing with solely this display
issue. Well here is that bug. REOPENING.
QA Contact: paulmac → claudius
Resolution: DUPLICATE → ---
the little voices also said this should be Buster's bug, clearing resolution.
Assignee: trudelle → buster
Status: REOPENED → NEW
reassigning to buster, per Claudius' last comment.
Status: NEW → ASSIGNED
Target Milestone: M14
Is this problem unique to chrome, or does it happen in a web page with jscript
used to show/hide the text control?  If anybody has a few minutes to test that,
it would be useful to know.  Something like this, though my CSS syntax is way
off I'm sure:
<style>
div#hidden { display: none; }  // or "hidden"?  probably "none"
</style>
<body>
<div>
  <input type=text>
</div>
<input type=button onClick="ToggleDivVisibility()">

The point is to show/hide the text control by showing/hiding the div, so the
frame re-construction code gets invoked.
*** Bug 19508 has been marked as a duplicate of this bug. ***
Assignee: buster → nisheeth
Status: ASSIGNED → NEW
Re-assigning this to myself for further investigation...
I'm attaching a test case based on the snippet provided in Steve's earlier 
message.  This works properly - you don't need to click inside the text field to 
make its contents appear.
Attached file test.html
I mistakenly thought that the problem was that the contents of the text field 
were not getting saved/restored.  I've investigated this a little more and am 
handing it back to you, Steve.

Here's the problem.  In the attached test.html which displays correct behavior, 
when you make the text field visible, the GFX text control's member 
variable, mDisplayFrame, is non-null when 
nsGfxTextControlFrame::PaintTextControl() is called.  So, PaintChild() gets 
called from PaintTextControl() and the contents of the text field display 
properly.

When you show/hide the url bar, however, mDisplayFrame is null when 
PaintTextControl() is called, so, PaintChild() never gets called.

Hope this analysis helps you...
Assignee: nisheeth → buster
thanks nisheeth, that does help a lot.  I should be able to nail this in M14.  
I'll bet what happens is when the frame gets reconstructed, it isn't smart 
enough to rebuild the private display subtree it owns.
Priority: P3 → P2
handing off to eric vaughan.  eric, the problem is the text control frame never 
gets an initial reflow when it is reconstructed.  no initial reflow, no text 
display.

the block code has special case handling for reflowing child frames to check for 
this kind of thing.  Box layout code must need the same sort of thing.  Here's 
the relevant code:

nsresult
nsBlockReflowContext::ReflowBlock(nsIFrame* aFrame,
                                  const nsRect& aSpace,
                                  PRBool aApplyTopMargin,
                                  nscoord aPrevBottomMargin,
                                  PRBool aIsAdjacentWithTop,
                                  nsMargin& aComputedOffsets,
                                  nsReflowStatus& aFrameReflowStatus)
{
  nsresult rv = NS_OK;
  mFrame = aFrame;
  mSpace = aSpace;

  // Get reflow reason set correctly. It's possible that a child was
  // created and then it was decided that it could not be reflowed
  // (for example, a block frame that isn't at the start of a
  // line). In this case the reason will be wrong so we need to check
  // the frame state.
  nsReflowReason reason = eReflowReason_Resize;
  nsFrameState state;
  aFrame->GetFrameState(&state);
  if (NS_FRAME_FIRST_REFLOW & state) {
    reason = eReflowReason_Initial;
  }
  ...

Notice how the parent checks the child (aFrame) frame's flags to see if it needs 
an initial reflow or not.

As Nisheeth discovered, this all works perfectly in HTML content where box 
layout is not involved, as shown by the attached test case.

Setting severity to major.  The URL field is no big deal, but this impacts the 
addressing widget on mail compose, and anywhere else a text control might be in 
a tree control that scrolls.
Assignee: buster → evaughan
Severity: normal → major
putting on beta1 radar
Status: NEW → ASSIGNED
Whiteboard: This is fixed will check in with dirty box landing.
*** Bug 25887 has been marked as a duplicate of this bug. ***
As my bug got verified as a dup as this, though its not exactly, I thought to 
add the problems I noticed to this bug report. If you unselect Navigator Toolbar 
from the View/Toolbars menu having the accual bar removed, when you reselect 
this toolbar, the toolbar not only doesn't display the text, it also completly 
stops working, aka I can't type into the location bar.
*** Bug 25100 has been marked as a duplicate of this bug. ***
*** Bug 26474 has been marked as a duplicate of this bug. ***
fixed.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
VERIFIED fixed on all platfroms with the 2000021008 builds
Status: RESOLVED → VERIFIED
No longer blocks: 16841
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: