Closed Bug 24406 Opened 25 years ago Closed 23 years ago

[PATCH]Password, Textfields, TextAreas print blank

Categories

(Core :: Printing: Output, defect, P1)

x86
All
defect

Tracking

()

VERIFIED FIXED
mozilla0.9.3

People

(Reporter: shrir, Assigned: dcone)

References

Details

(Keywords: testcase)

Attachments

(7 files)

I used today's commercial build on Linux (2000011908M13).
to recreate the problem :

1. Install and launch mozilla
2. Click on the attachment.
3. A HTML password field is seen on the page
4. Select "FILE|PRINT" to print.
5. Observe that the page prints blank.
Attached file Test case attached
OS: Linux → All
Also seen on Windows(2000011908) and Mac(2000011910) commercial builds for
today. Marking OS ALL.
Similarly,a HTML textarea also prints blank on all platforms. Attaching a test
case for that.
Attached file Textarea testcase
Status: NEW → ASSIGNED
This is because the webshell for that widget requires a webshell with a native
widget.. that has a scriptmanager for the DOM to work.  It does not, so the
document..(or password) cannot be loaded.
*** Bug 24494 has been marked as a duplicate of this bug. ***
Target Milestone: M14
*** Bug 24534 has been marked as a duplicate of this bug. ***
*** Bug 10578 has been marked as a duplicate of this bug. ***
Summary: Password field prints blank → [PRINT TEXTFIELD]Password field prints blank
Target Milestone: M14 → M15
Keywords: beta1
Putting on PDT- radar for beta1.  Won't hold beta for this.
Whiteboard: [PDT-]
This is also related to 28878, the print jobs do not have native widgets.. so 
any requirement of the webshell for a native widget will assert for printing. 
Can you look at this Travis.
Assignee: dcone → travis
Status: ASSIGNED → NEW
Flipping to Kevin.  I think there is actually a master remove native widgets 
bug that these should be made to be a dependency of.
Assignee: travis → kmcclusk
Adding dependency on native widget removal bug.
Depends on: 31468
In nsWindow::StandardWindowCreate the aParent and aNativeParent are being passed 
in null, then when the ::CreateWindowEx, it fails to create a mWnd (which is 
should not for a printer).  The VERIFY is then called which asserts.  Somehow 
this code path should not get called, or depend on having a mWnd when 
CreateWidget() is called.. since this will fail for a printer.
*** Bug 32434 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Target Milestone: M15 → M16
Moving to M17
Target Milestone: M16 → M17
The basic problem is that native widgets are not created during printing, but 
portions of the XP-code expect to be able to ask a widget for it's native widget 
handle.

Need a general solution for this problem. TextAreas, password fields, and 
framesets all share this same problem.

One possible solution is to create a native widget during printing which is an 
instance of a nsBaseWidget. The native widget handle passed around in the XPCODE 
is opaque so creating the nsBaseWidget may be sufficient.

Reassigning to dcone to determine if the nsBaseWidget solution will work.
Assignee: kmcclusk → dcone
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
just wanted to point out that lightweight ender text controls are on the way for 
nsbeta2, so don't waste time testing against textareas.  focus on framesets.  
should the summary be changed accordingly?
cc-ing mjudge just to make him aware of the issue.
*** Bug 43514 has been marked as a duplicate of this bug. ***
The password field will now print (lightweight ender text controls fixed this), 
but the new state in one frame model is not reflected in the new frame model 
created to print.  This state needs to be updated in the new frame model created 
from the document.  I will research this further to see if I can fix this before 
dishing it off to anyone else.
Keywords: beta1nsbeta3
Changed status from

[PRINT TEXTFIELD]Password field prints blank

to

[PRINT TEXTFIELD]Password, Textfields and TextAreas prints blank

If only affects passwords then we recomment nsbeta3-

Summary: [PRINT TEXTFIELD]Password field prints blank → [PRINT TEXTFIELD]Password, Textfields and TextAreas prints blank
Whiteboard: [PDT-] → [PDT-][nsbeta3+]
Setting priority to P1
Priority: P3 → P1
I just confirmed that Text fields, textarea still do not print their contents. 
They print their default contents instead of what the user entered.
PDT agrees P1
Putting [pdtp1] in whiteboard
Whiteboard: [PDT-][nsbeta3+] → [PDT-][nsbeta3+][pdtp1]
would not hold pr3 for this
Clearing dependency on bug 31468
No longer depends on: 31468
marking nsbeta3- per my earlier comment.  Nominating for rtm.
Keywords: rtm
Whiteboard: [PDT-][nsbeta3+][pdtp1] → [PDT-][nsbeta3-][pdtp1]
Marking rtm+.
Whiteboard: [PDT-][nsbeta3-][pdtp1] → [rtm+][PDT-][nsbeta3-][pdtp1]
Marking [rtm need info] Waiting for patch to be attached, review + super-review.
Whiteboard: [rtm+][PDT-][nsbeta3-][pdtp1] → [rtm need info][PDT-][nsbeta3-][pdtp1]
shorter title
Summary: [PRINT TEXTFIELD]Password, Textfields and TextAreas prints blank → [PRINT TEXTFIELD]Password, Textfields, TextAreas print blank
Depends on: 55385
*** Bug 56567 has been marked as a duplicate of this bug. ***
don: patch looks good, except you should check to make sure you have a valid fm
before dereferencing it.  something like:
    // update the history from the old presentation shell
    nsCOMPtr<nsIFrameManager> fm;
    rv = ps->GetFrameManager(getter_AddRefs(fm));
    if (NS_SUCCEEDED(rv) && fm) {
      nsIFrame* root;
      ps->GetRootFrame(&root);
      fm->RestoreFrameState(cx, root, layoutState);
    }
    ps->EndObservingDocument();
Patch looks good.
r=kmcclusk@netscape.com.
Marking rtm+.

Whiteboard: [rtm need info][PDT-][nsbeta3-][pdtp1] → [rtm+][PDT-][nsbeta3-][pdtp1]
*** Bug 55385 has been marked as a duplicate of this bug. ***
Checked this into the trunk.  
Just to be explicit, we'd like sr= on the actual patch now. Marking [rtm need info]
Whiteboard: [rtm+][PDT-][nsbeta3-][pdtp1] → [rtm need info][PDT-][nsbeta3-][pdtp1]
sr=buster
should now be moved to rtm+
Whiteboard: [rtm need info][PDT-][nsbeta3-][pdtp1] → [rtm need info][PDT-][nsbeta3-][pdtp1] Checked into trunk
Marking rtm+.
Whiteboard: [rtm need info][PDT-][nsbeta3-][pdtp1] Checked into trunk → [rtm+][PDT-][nsbeta3-][pdtp1] Checked into trunk
rtm++
Whiteboard: [rtm+][PDT-][nsbeta3-][pdtp1] Checked into trunk → [rtm++][PDT-][nsbeta3-][pdtp1] Checked into trunk
Using the history to get the current content for the printout.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Keywords: vtrunk
This looks good on today's branch builds on mac/windows/linux. Adding:vtrunk to 
get verified on trunk builds. Bottom borders of textfield/textbox print very 
faint on linux. I will file a seperate bug for that.
verified on all trunk builds (11/27)
Status: RESOLVED → VERIFIED
Keywords: vtrunk
Mozilla 0.8 (release) and the nightly again don't print filled in forms. Can
this bug be reopened or do I have to file a new bug? (newbe)
sujay, please check and reopen if regressed...
QA Contact: shrir → sujay
*** Bug 71307 has been marked as a duplicate of this bug. ***
Reopening based on multiple comments that this has regressed.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
The password field comes out blank.. but the textfield has data in it.
I think the password field should be blank anyway, or the asteriks.. but that is 
another bug.  There is another bug about check boxes and radio buttons not 
printing.. but from my tests.. the textfields do print.
Status: REOPENED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → WORKSFORME
I wanted it to be reopened because text typed in textfields (by yourself) is not
printed. (not only passwords)
verified in 3/9 build.
Status: RESOLVED → VERIFIED
The original bug is in my opinion partly resolved. But when you fill out
http://bugzilla.mozilla.org/query.cgi in random boxes like "Email" and "A
description entry" and you print it, this text is not printed. The output is
empty text-boxes.
reopening.  Broken with the 2001-04-23-08 linux nightly and builds from 2001-04-24.

Attaching testcase
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
*** Bug 77366 has been marked as a duplicate of this bug. ***
*** Bug 78951 has been marked as a duplicate of this bug. ***
SPAM: mozilla 0.9 (and M1, and 0.8.1, etc.) has left the building.  please
update the target milestone so we can get a good idea of what's left for 0.9.1.
Keywords: nsbeta3, rtmtestcase
Whiteboard: [rtm++][PDT-][nsbeta3-][pdtp1] Checked into trunk
Target Milestone: M17 → ---
10 bugs according to http://bugzilla.mozilla.org/duplicates.cgi. Marking mostfreq.
Keywords: mostfreq
Target Milestone: --- → mozilla0.9.2
Keywords: nsBranch
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Summary: [PRINT TEXTFIELD]Password, Textfields, TextAreas print blank → [PATCH]Password, Textfields, TextAreas print blank
patch 40460 looks good. r=kmcclusk@netscape.com
sr=attinasi
Checked into the trunk.
adding vtrunk keyword since this bug has been fixed and checked into the trunk.
 Bug is left open (not marked fixed/resolved), in hopes to check the patch into
the branch also.  vtrunk keyword will indicate the bug should be verified on the
trunk, if possible.
Keywords: vtrunk
checked into .92 branch
Status: REOPENED → RESOLVED
Closed: 24 years ago23 years ago
Resolution: --- → FIXED
verified on 7/9 trunk...will verify on branch and post comments again here.
removing vtrunk keyword...already verified on trunk.
Keywords: vtrunk
verified on 7/9 branch and trunk builds.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: