Closed
Bug 433778
Opened 17 years ago
Closed 2 years ago
Copy and Paste broken in Print dialog on Mac OS X
Categories
(Core :: Widget: Cocoa, defect, P3)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: daniel, Unassigned)
References
Details
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008051404 Minefield/3.0pre
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008051404 Minefield/3.0pre
'Copy and paste' between Mozilla Firefox and Mac OS X is broken if not the mouse but the respective keyboard shortcuts are used.
Reproducible: Always
Steps to Reproduce:
1. Open any Web page and copy some text (Command-C or mouse);
2. Command-P (print), then 'Save as PDF';
3. Paste the before-copied text as file name by using Command-V.
Actual Results:
Nil.
Expected Results:
Pasting of before-copied text as file name
Using the mouse (right-click context menu) instead of keyboard works.
Comment 1•17 years ago
|
||
I've confirmed this.
Edit : Paste is grayed out in step 3, and the dialog you're trying to
paste into is a window created by the OS (not one created by the
browser).
This problem is probably related to bug 425844 and bug 426990 (though
it isn't a dup of either bug).
Status: UNCONFIRMED → NEW
Component: OS Integration → Widget: Cocoa
Ever confirmed: true
Product: Firefox → Core
Version: unspecified → Trunk
Updated•17 years ago
|
Flags: wanted1.9.0.x?
Priority: -- → P2
Updated•17 years ago
|
Assignee: nobody → joshmoz
QA Contact: os.integration → cocoa
Updated•17 years ago
|
Flags: in-litmus?
QA Contact: cocoa → os.integration
Updated•17 years ago
|
QA Contact: os.integration → cocoa
Comment 2•17 years ago
|
||
Using the context menu in step 4 does the job. I can paste the copied text. It looks like that the global shortcut is disabled.
Hardware: Macintosh → All
Command-A (select all) is not working either in the 'save' dialog.
Comment 4•17 years ago
|
||
Firefox 2.0.0.14 on Mac OS X 10.3.9 incorrectly transliterates newline characters to carriage return characters when copying text from HTML rendered in Firefox. Steps to reproduce:
1. Open an HTML document which contains no carriage return characters (\r; octal 012) in Firefox 2.0.0.14 on Mac OS X [10.3].
2. Select a portion of the text rendered in the browser which spans multiple lines.
3. Select "Edit -> Copy" from the menu.
4. Open TextEdit (a native Mac OS X app, roughly analogous to Microsoft's Notepad).
5. Select "Edit -> Paste" from the menu.
6. Save the file and examine it with a utility like /usr/bin/od (or a hexdump utility, etc). For example:
/usr/bin/od -c $file_saved_in_TextEdit | fgrep \\r
Shall I create a new bug report for the defect?
(In reply to comment #4)
> Firefox 2.0.0.14 on Mac OS X 10.3.9 incorrectly transliterates newline
[...]
> Shall I create a new bug report for the defect?
If you can reproduce it in the latest Firefox 3 release candidate (which requires 10.4 or newer), please do. Firefox 2 is only receiving security and stability updates at this point, so if the bug only exists there, it's not really worth filing a report.
Updated•17 years ago
|
Summary: Copy and Paste between Mozilla Firefox and Mac OS X broken → Copy and Paste broken in Print dialog on Mac OS X
Is it a Firefox or an Apple problem? In Firefox 3.0.1pre, the problem is still reproducible.
This is a problem with Gecko. We have to rewrite our print dialog code in Cocoa (it is still Carbon in Gecko 1.9.0) and then we can fix this. Without a Cocoa print dialog we can't do what we need to do with the menu bar for the print dialog.
Thank you for your update, Josh. I had reported the bug to Apple on 28 May 2008 and received the following feedback yesterday:
'Engineering has determined that this issue originates with Firefox. Please feel free to contact Firefox regarding this issue to help alert them of its importance.'
Comment 10•16 years ago
|
||
(In reply to comment #8)
> This is a problem with Gecko. We have to rewrite our print dialog code in Cocoa
> (it is still Carbon in Gecko 1.9.0) and then we can fix this.
And that's not going to happen in a maintenance release, but should get considered for 1.9.1.
Flags: wanted1.9.1?
Flags: wanted1.9.0.x?
Flags: wanted1.9.0.x-
Flags: blocking1.9.1?
Flags: wanted1.9.1?
Flags: wanted1.9.1+
Flags: blocking1.9.1?
Flags: blocking1.9.1-
Reporter | ||
Comment 11•16 years ago
|
||
The problem is still reproducible in one of the latest Mozilla Firefox versions:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090103 Minefield/3.2a1pre Ubiquity/0.1.4
Comment 12•16 years ago
|
||
Markus, would this be some kind easy to fix?
Comment 13•16 years ago
|
||
Rewriting our print dialog code in Cocoa doesn't sound that easy ;-)
Comment 14•16 years ago
|
||
That's true. I forgot this detail. In that case it has to wait until bug 456646 is fixed.
Depends on: 456646
Comment 18•15 years ago
|
||
Bug 456646 fixes this.
Updated•15 years ago
|
Whiteboard: [will be fixed by bug 456646]
Comment 19•15 years ago
|
||
Uh... apparently not. What made me think so? Maybe it's fixed on 10.6?
Assignee: mstange → nobody
No longer depends on: 456646
Updated•15 years ago
|
Whiteboard: [will be fixed by bug 456646]
Comment 20•6 years ago
|
||
Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P2 → P3
Updated•2 years ago
|
Severity: normal → S3
Comment 21•2 years ago
|
||
The severity field for this bug is relatively low, S3. However, the bug has 4 duplicates.
:spohl, could you consider increasing the bug severity?
For more information, please visit auto_nag documentation.
Flags: needinfo?(spohl.mozilla.bugs)
Comment 22•2 years ago
|
||
The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.
Flags: needinfo?(spohl.mozilla.bugs)
Updated•2 years ago
|
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•