Closed
Bug 24406
Opened 25 years ago
Closed 23 years ago
[PATCH]Password, Textfields, TextAreas print blank
Categories
(Core :: Printing: Output, defect, P1)
Tracking
()
VERIFIED
FIXED
mozilla0.9.3
People
(Reporter: shrir, Assigned: dcone)
References
Details
(Keywords: testcase)
Attachments
(7 files)
145 bytes,
text/html
|
Details | |
237 bytes,
text/html
|
Details | |
1.60 KB,
patch
|
Details | Diff | Splinter Review | |
1.65 KB,
patch
|
Details | Diff | Splinter Review | |
153 bytes,
text/html
|
Details | |
1.58 KB,
patch
|
Details | Diff | Splinter Review | |
952 bytes,
patch
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•25 years ago
|
||
Reporter | ||
Updated•25 years ago
|
OS: Linux → All
Reporter | ||
Comment 2•25 years ago
|
||
Also seen on Windows(2000011908) and Mac(2000011910) commercial builds for today. Marking OS ALL.
Reporter | ||
Comment 3•25 years ago
|
||
Similarly,a HTML textarea also prints blank on all platforms. Attaching a test case for that.
Reporter | ||
Comment 4•25 years ago
|
||
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 5•25 years ago
|
||
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.
Assignee | ||
Updated•25 years ago
|
Target Milestone: M14
Assignee | ||
Updated•25 years ago
|
Summary: Password field prints blank → [PRINT TEXTFIELD]Password field prints blank
Assignee | ||
Updated•25 years ago
|
Target Milestone: M14 → M15
Putting on PDT- radar for beta1. Won't hold beta for this.
Whiteboard: [PDT-]
Assignee | ||
Comment 10•25 years ago
|
||
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
Comment 11•25 years ago
|
||
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
Assignee | ||
Comment 13•24 years ago
|
||
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.
Assignee | ||
Comment 14•24 years ago
|
||
*** Bug 32434 has been marked as a duplicate of this bug. ***
Updated•24 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M15 → M16
Comment 16•24 years ago
|
||
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
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Comment 17•24 years ago
|
||
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.
Assignee | ||
Comment 18•24 years ago
|
||
*** Bug 43514 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 19•24 years ago
|
||
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.
Assignee | ||
Updated•24 years ago
|
Comment 20•24 years ago
|
||
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+]
Comment 22•24 years ago
|
||
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•24 years ago
|
||
PDT agrees P1
Comment 24•24 years ago
|
||
Putting [pdtp1] in whiteboard
Whiteboard: [PDT-][nsbeta3+] → [PDT-][nsbeta3+][pdtp1]
Comment 25•24 years ago
|
||
would not hold pr3 for this
Comment 27•24 years ago
|
||
marking nsbeta3- per my earlier comment. Nominating for rtm.
Keywords: rtm
Whiteboard: [PDT-][nsbeta3+][pdtp1] → [PDT-][nsbeta3-][pdtp1]
Comment 28•24 years ago
|
||
Marking rtm+.
Whiteboard: [PDT-][nsbeta3-][pdtp1] → [rtm+][PDT-][nsbeta3-][pdtp1]
Comment 29•24 years ago
|
||
Marking [rtm need info] Waiting for patch to be attached, review + super-review.
Whiteboard: [rtm+][PDT-][nsbeta3-][pdtp1] → [rtm need info][PDT-][nsbeta3-][pdtp1]
Comment 30•24 years ago
|
||
shorter title
Summary: [PRINT TEXTFIELD]Password, Textfields and TextAreas prints blank → [PRINT TEXTFIELD]Password, Textfields, TextAreas print blank
Assignee | ||
Comment 31•24 years ago
|
||
*** Bug 56567 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 32•24 years ago
|
||
Comment 33•24 years ago
|
||
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();
Assignee | ||
Comment 34•24 years ago
|
||
Comment 35•24 years ago
|
||
Patch looks good. r=kmcclusk@netscape.com. Marking rtm+.
Whiteboard: [rtm need info][PDT-][nsbeta3-][pdtp1] → [rtm+][PDT-][nsbeta3-][pdtp1]
Assignee | ||
Comment 36•24 years ago
|
||
*** Bug 55385 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 37•24 years ago
|
||
Checked this into the trunk.
Comment 38•24 years ago
|
||
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]
Comment 39•24 years ago
|
||
sr=buster
Comment 40•24 years ago
|
||
should now be moved to rtm+
Whiteboard: [rtm need info][PDT-][nsbeta3-][pdtp1] → [rtm need info][PDT-][nsbeta3-][pdtp1] Checked into trunk
Comment 41•24 years ago
|
||
Marking rtm+.
Whiteboard: [rtm need info][PDT-][nsbeta3-][pdtp1] Checked into trunk → [rtm+][PDT-][nsbeta3-][pdtp1] Checked into trunk
Comment 42•24 years ago
|
||
rtm++
Whiteboard: [rtm+][PDT-][nsbeta3-][pdtp1] Checked into trunk → [rtm++][PDT-][nsbeta3-][pdtp1] Checked into trunk
Assignee | ||
Comment 43•24 years ago
|
||
Using the history to get the current content for the printout.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 44•24 years ago
|
||
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.
Reporter | ||
Comment 45•24 years ago
|
||
verified on all trunk builds (11/27)
Status: RESOLVED → VERIFIED
Keywords: vtrunk
Comment 46•23 years ago
|
||
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)
Reporter | ||
Comment 47•23 years ago
|
||
sujay, please check and reopen if regressed...
QA Contact: shrir → sujay
Comment 48•23 years ago
|
||
*** 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 → ---
Assignee | ||
Comment 50•23 years ago
|
||
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 ago → 23 years ago
Resolution: --- → WORKSFORME
Comment 51•23 years ago
|
||
I wanted it to be reopened because text typed in textfields (by yourself) is not printed. (not only passwords)
Comment 53•23 years ago
|
||
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•23 years ago
|
||
reopening. Broken with the 2001-04-23-08 linux nightly and builds from 2001-04-24. Attaching testcase
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
Comment 55•23 years ago
|
||
Comment 56•23 years ago
|
||
*** Bug 77366 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
Keywords: mozilla1.0,
nsbeta1
Assignee | ||
Comment 57•23 years ago
|
||
*** Bug 78951 has been marked as a duplicate of this bug. ***
Comment 58•23 years ago
|
||
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•23 years ago
|
||
10 bugs according to http://bugzilla.mozilla.org/duplicates.cgi. Marking mostfreq.
Keywords: mostfreq
Updated•23 years ago
|
Target Milestone: --- → mozilla0.9.2
Assignee | ||
Comment 60•23 years ago
|
||
Assignee | ||
Updated•23 years ago
|
Summary: [PRINT TEXTFIELD]Password, Textfields, TextAreas print blank → [PATCH]Password, Textfields, TextAreas print blank
Assignee | ||
Comment 61•23 years ago
|
||
Comment 62•23 years ago
|
||
patch 40460 looks good. r=kmcclusk@netscape.com
Comment 63•23 years ago
|
||
sr=attinasi
Assignee | ||
Comment 64•23 years ago
|
||
Checked into the trunk.
Comment 65•23 years ago
|
||
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
Assignee | ||
Comment 66•23 years ago
|
||
checked into .92 branch
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Comment 67•23 years ago
|
||
verified on 7/9 trunk...will verify on branch and post comments again here.
You need to log in
before you can comment on or make changes to this bug.
Description
•