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)
Core
XUL
Tracking
()
VERIFIED
FIXED
M14
People
(Reporter: bugzilla, Assigned: eric)
References
Details
(Whiteboard: This is fixed will check in with dirty box landing.)
Attachments
(1 file)
488 bytes,
text/html
|
Details |
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
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 2•25 years ago
|
||
verified
Updated•25 years ago
|
Status: VERIFIED → REOPENED
Comment 3•25 years ago
|
||
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.
Updated•25 years ago
|
QA Contact: paulmac → claudius
Resolution: DUPLICATE → ---
Comment 4•25 years ago
|
||
the little voices also said this should be Buster's bug, clearing resolution.
Updated•25 years ago
|
Assignee: trudelle → buster
Status: REOPENED → NEW
Comment 5•25 years ago
|
||
reassigning to buster, per Claudius' last comment.
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.
Updated•25 years ago
|
Assignee: buster → nisheeth
Status: ASSIGNED → NEW
Comment 8•25 years ago
|
||
Re-assigning this to myself for further investigation...
Comment 9•25 years ago
|
||
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.
Comment 10•25 years ago
|
||
Comment 11•25 years ago
|
||
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
Comment 12•25 years ago
|
||
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
Comment 13•25 years ago
|
||
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
Comment 14•25 years ago
|
||
putting on beta1 radar
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Whiteboard: This is fixed will check in with dirty box landing.
Comment 15•25 years ago
|
||
*** Bug 25887 has been marked as a duplicate of this bug. ***
Comment 16•25 years ago
|
||
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.
Comment 17•25 years ago
|
||
*** Bug 25100 has been marked as a duplicate of this bug. ***
Comment 18•25 years ago
|
||
*** Bug 26474 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 19•25 years ago
|
||
fixed.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Comment 20•25 years ago
|
||
VERIFIED fixed on all platfroms with the 2000021008 builds
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•