24406 - [PATCH]Password, Textfields, TextAreas print blank

Status: VERIFIED FIXED

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

Description

[shrirang khanzode]

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.

Comment 1

[shrirang khanzode]

Attachment: Test case attached

Comment 2

[shrirang khanzode]

Also seen on Windows(2000011908) and Mac(2000011910) commercial builds for
today. Marking OS ALL.

Comment 3

[shrirang khanzode]

Similarly,a HTML textarea also prints blank on all platforms. Attaching a test
case for that.

Comment 4

[shrirang khanzode]

Attachment: Textarea testcase

Comment 5

[dcone (gone)]

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.

Comment 6

[dcone (gone)]

*** Bug 24494 has been marked as a duplicate of this bug. ***

Comment 7

[dcone (gone)]

*** Bug 24534 has been marked as a duplicate of this bug. ***

Comment 8

[dcone (gone)]

*** Bug 10578 has been marked as a duplicate of this bug. ***

Comment 9

[leger]

Putting on PDT- radar for beta1.  Won't hold beta for this.

Comment 10

[dcone (gone)]

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.

Comment 11

[travis]

Flipping to Kevin.  I think there is actually a master remove native widgets 
bug that these should be made to be a dependency of.

Comment 12

[travis]

Adding dependency on native widget removal bug.

Comment 13

[dcone (gone)]

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.

Comment 14

[dcone (gone)]

*** Bug 32434 has been marked as a duplicate of this bug. ***

Comment 15

[Kevin McCluskey (gone)]

Moving to M17

Comment 16

[Kevin McCluskey (gone)]

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.

Comment 17

[buster]

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.

Comment 18

[dcone (gone)]

*** Bug 43514 has been marked as a duplicate of this bug. ***

Comment 19

[dcone (gone)]

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.

Comment 20

[Kevin McCluskey (gone)]

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-

Comment 21

[Kevin McCluskey (gone)]

Setting priority to P1

Comment 22

[Kevin McCluskey (gone)]

I just confirmed that Text fields, textarea still do not print their contents. 
They print their default contents instead of what the user entered.

Comment 23

[leger]

PDT agrees P1

Comment 24

[leger]

Putting [pdtp1] in whiteboard

Comment 25

[Michael La Guardia]

would not hold pr3 for this

Comment 26

[Kevin McCluskey (gone)]

Clearing dependency on bug 31468

Comment 27

[Michael La Guardia]

marking nsbeta3- per my earlier comment.  Nominating for rtm.

Comment 28

[Kevin McCluskey (gone)]

Marking rtm+.

Comment 29

[Kevin McCluskey (gone)]

Marking [rtm need info] Waiting for patch to be attached, review + super-review.

Comment 30

[Chris McAfee]

shorter title

Comment 31

[dcone (gone)]

*** Bug 56567 has been marked as a duplicate of this bug. ***

Comment 32

[dcone (gone)]

Attachment: Patch for nsDocumentViewer which uses history to update content.

Comment 33

[buster]

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();

Comment 34

[dcone (gone)]

Attachment: new patch with Steve's suggestions. Tested this patch also.

Comment 35

[Kevin McCluskey (gone)]

Patch looks good.
r=[e-mail].
Marking rtm+.

Comment 36

[dcone (gone)]

*** Bug 55385 has been marked as a duplicate of this bug. ***

Comment 37

[dcone (gone)]

Checked this into the trunk.  

Comment 38

[Phil Peterson]

Just to be explicit, we'd like sr= on the actual patch now. Marking [rtm need info]

Comment 39

[buster]

sr=buster

Comment 40

[Jason Eager]

should now be moved to rtm+

Comment 41

[Kevin McCluskey (gone)]

Marking rtm+.

Comment 42

[Phil Peterson]

rtm++

Comment 43

[dcone (gone)]

Using the history to get the current content for the printout.

Comment 44

[shrirang khanzode]

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.

Comment 45

[shrirang khanzode]

verified on all trunk builds (11/27)

Comment 46

[Mark Brio]

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)

Comment 47

[shrirang khanzode]

sujay, please check and reopen if regressed...

Comment 48

[Oliver Klee]

*** Bug 71307 has been marked as a duplicate of this bug. ***

Comment 49

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Reopening based on multiple comments that this has regressed.

Comment 50

[dcone (gone)]

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.

Comment 51

[Mark Brio]

I wanted it to be reopened because text typed in textfields (by yourself) is not
printed. (not only passwords)

Comment 52

[sujay]

verified in 3/9 build.

Comment 53

[Mark Brio]

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.

Comment 54

[Boris Zbarsky [:bzbarsky]]

reopening.  Broken with the 2001-04-23-08 linux nightly and builds from 2001-04-24.

Attaching testcase

Comment 55

[Boris Zbarsky [:bzbarsky]]

Attachment: testcase using <input type="text">

Comment 56

[Boris Zbarsky [:bzbarsky]]

*** Bug 77366 has been marked as a duplicate of this bug. ***

Comment 57

[dcone (gone)]

*** Bug 78951 has been marked as a duplicate of this bug. ***

Comment 58

[Jon Granrose]

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.

Comment 59

[Jacek Piskozub]

10 bugs according to http://bugzilla.mozilla.org/duplicates.cgi. Marking mostfreq.

Comment 60

[dcone (gone)]

Attachment: Patch fixes the way a selection is reported.

Comment 61

[dcone (gone)]

Attachment: better patch..without old patch stuff.

Comment 62

[Kevin McCluskey (gone)]

patch 40460 looks good. r=[e-mail]

Comment 63

[Marc Attinasi]

sr=attinasi

Comment 64

[dcone (gone)]

Checked into the trunk.

Comment 65

[lchiang]

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.

Comment 66

[dcone (gone)]

checked into .92 branch

Comment 67

[sujay]

verified on 7/9 trunk...will verify on branch and post comments again here.

Comment 68

[sujay]

removing vtrunk keyword...already verified on trunk.

Comment 69

[sujay]

verified on 7/9 branch and trunk builds.