Closed Bug 340071 Opened 18 years ago Closed 18 years ago

[mac only] pasting html from ff 1.5.0.4 into compose window in tb 1.5.0.4 doesn't paste anything

Categories

(Thunderbird :: Message Compose Window, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: moco, Assigned: mark)

References

Details

(Keywords: fixed1.8.1, verified1.8.0.5, verified1.8.1.3)

Attachments

(1 file, 1 obsolete file)

pasting html from ff 1.5.0.4 into compose window in tb 1.5.0.4 doesn't past anything.

see #334883 for some background on this issue.

note, ff 1.5.0.4 is a UB but tb 1.5.0.4 is not.  when I've used a test tb universal binary build, paste works.
according to the 1.5.0.4 tb rel notes, it is supposed to be a UB!

From http://www.mozilla.com/thunderbird/releases/1.5.0.4.html

Here's what's new in Thunderbird 1.5.0.4:

    * Universal Binary Support for Mac OS X which provides native support for Macintosh with Intel Core processors. Thunderbird supports the enhancements to performance introduced by the new MacIntel chipsets.

but when I do:

$ file /Applications/Thunderbird.app/Contents/MacOS/thunderbird-bin 

I get:

/Applications/Thunderbird.app/Contents/MacOS/thunderbird-bin: Mach-O executable ppc

notice:

$ /Applications/Thunderbird.app/Contents/MacOS/thunderbird-bin --v
 Thunderbird 1.5.0.4, Copyright (c) 2005 mozilla.org
odd, the tbird I get when I download the .dmg is a UB, but what I ended up with when doing an update from inside TB (from 1.5.0.2) gave me only the ppc version!

file ~/Desktop/Thunderbird.app/Contents/MacOS/thunderbird-bin 
/Users/sspitzer/Desktop/Thunderbird.app/Contents/MacOS/thunderbird-bin: Mach-O universal binary with 2 architectures
/Users/sspitzer/Desktop/Thunderbird.app/Contents/MacOS/thunderbird-bin (for architecture i386): Mach-O executable i386
/Users/sspitzer/Desktop/Thunderbird.app/Contents/MacOS/thunderbird-bin (for architecture ppc):  Mach-O executable ppc
sure enough, pasting from ff 1.5.0.4 into tb 1.5.0.4 UB works fine. 

so maybe the real issue is that when I upgraded from 1.5.0.2 to 1.5.0.4 I did not get a the UB version, I only got the PPC version.
Right, if you upgrade via automatic update then you will not get UB. You only get UB if you download from the website.
This is probably the same cautious upgrade path that was used when Firefox first went universal in 1.5.0.2: existing ppc versions would auto-update to ppc, but new downloads were universal.  I think that as of 1.5.0.4, older ppc Firefoxes will auto-update to universal, now that everyone's satisfied that the universal builds are in fact better than sliced bread.
So, the original issue that I was seeing was that pasting into Thunderbird running under Rosetta from Firefox was mangling the paste data, in most cases causing nothing to be pasted at all. Universal binaries will "fix" the bug by causing Thunderbird to not have to run under Rosetta, but IMO that's a side issue.

Figuring out why Thunderbird running under Rosetta mangles pastes from would solve this bug, universal binaries or not.
Yup, I consider this a bug even with the "workaround" of running universal.  Running under Rosetta is supposed to be a viable configuration.
I've spun the "upgrade from 1.5.0.2 -> 1.5.0.4 doesn't result in a UB" to bug #340137
Summary: [mac only] pasting html from ff 1.5.0.4 into compose window in tb 1.5.0.4 doesn't past anything → [mac only] pasting html from ff 1.5.0.4 into compose window in tb 1.5.0.4 doesn't paste anything
(In reply to comment #1)
> according to the 1.5.0.4 tb rel notes, it is supposed to be a UB!
> 
> From http://www.mozilla.com/thunderbird/releases/1.5.0.4.html
> 
> Here's what's new in Thunderbird 1.5.0.4:
> 
>     * Universal Binary Support for Mac OS X which provides native support for
> Macintosh with Intel Core processors. Thunderbird supports the enhancements to
> performance introduced by the new MacIntel chipsets.


the release notes also say (just like the Fx 1.5.0.2 notes):

"If you are running Thunderbird 1.5 or Thunderbird 1.5.0.2 on Macintosh computers with Intel Core processors under Rosetta, you will get upgraded to a PowerPC-only, Firefox 1.5.0.4 product via the automated update system. You will need to download the Thunderbird 1.5.0.4 Universal Binary build from www.mozilla.com to take advantage of the native support for Intel-based Macintosh computers."

:)
This bug also happens the other way around. Given a Thunderbird PPC build running under Rosetta, drag and drop a link into Firefox. The pasted URL is incorrect: in my case, I get a google search for something that looks like byte-swapped UTF-8 (or deleted memory), which is (I believe) the default behavior for unresolveable URLs.
Attached patch Patch (obsolete) — Splinter Review
Moderate hack alert - but when you're reading and writing data through void pointers like this, there's not much else you can do.

This patch forces any Mozilla flavor (the 'MZ..' flavors) to be read from and written to the clipboard using the native host machine's endianness - that is, if running under Rosetta, the data for 'MZ' flavors will be byte-swapped.  I'm not positive all 'MZ' flavors are actually utf-16 data, and that might be a problem.  The comments in widget indicate that they are, but more inspection may be necessary.
Assignee: mscott → mark
Status: NEW → ASSIGNED
Flags: blocking1.8.0.5?
Mark, could this fix/help bug 336012?
No.
Comment on attachment 224469 [details] [diff] [review]
Patch

I don't feel so bad about this because there are other parts of the code that assume these types (and many more) will be text, so going for review.
Attachment #224469 - Flags: review?(joshmoz)
So this patch changes interfaces which we don't want to do on the 1.8.* branches. And since we're moving to UB for both TB and FF this will be a non-issue soon it seems like?
Yes, this is annoying (I see it all the time since I now am a proud owner of a MacBook Pro), but hopefully TB and FF 1.5.0.5 will not have this issue after both are UB.
Flags: blocking1.8.0.5? → blocking1.8.0.5-
Not quite.  Running under Rosetta is still perfectly valid, even when both Firefox and Thunderbird are universal, for users who need to run binary extensions that aren't yet x86-native.

I don't think the interface change is such a significant issue in this case, as this interface was introduced in 1.8.0.2.  The check can be done outside of MacUtils if needed, but I don't think it's really a significant concern.
Feel free to get this landed on trunk, but we can't take it on any branches since it changes APIs. Though of course if it's possible to fix this without API changes we could reconsider.
I can extend the interface to nsIMacUtils_branchname, which I think is a little ridiculous for an interface only introduced in 1.8.0.2, but whatever.
Sibling bug 340890 for drag'n'drop.
Attached patch v2Splinter Review
Attachment #225050 - Flags: review?(joshmoz)
Attachment #224469 - Attachment is obsolete: true
Attachment #224469 - Flags: review?(joshmoz)
I guess if it's already new post-1.5 then the API must be safely "internal" and we can change it. Thanks for clarifying that.
Flags: blocking1.8.0.5- → blocking1.8.0.5+
Attachment #225050 - Flags: review?(joshmoz) → review+
Attachment #225050 - Flags: superreview?(mikepinkerton)
Comment on attachment 225050 [details] [diff] [review]
v2

sr=pink

why change the IID again? if the interface isn't frozen, it's ok to change. If it is frozen, you need to extend it by creating a new interface.
Attachment #225050 - Flags: superreview?(mikepinkerton) → superreview+
Attachment #225050 - Flags: approval-branch-1.8.1+
Checked in on trunk and 1.8 branch for 1.8.1b1.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
Comment on attachment 225050 [details] [diff] [review]
v2

approved for 1.8.0 branch, a=dveditz for drivers
Attachment #225050 - Flags: approval1.8.0.5+
People use interfaces that aren't frozen so we've desided to rev the iid on even non-frozen interfaces. That way such users will fail rather then crash (assuming they check if the QI succeeds)
Checked in on MOZILLA_1_8_0_BRANCH for 1.8.0.5.
Keywords: fixed1.8.0.5
Cutting from FF 1.5.0.3 UB and pasting onto compose window in TB 1.5.0.4 running under Rosetta works, but if you use FF 1.5.0.4 UB it doesn't work. (just for reference)

I verified that now you can copy from FF 1.5.0.5 onto a compose window in TB 1.5.0.4 running under Rosetta, using this FF build:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.5) Gecko/20060620 Firefox/1.5.0.5
Status: RESOLVED → VERIFIED
verified fixed on the 1.8 branch using the Tbird cand build, version 2.0.0.0 (20070326). I tested on an Intel Mac, and several cut and pastes from Firefox 2.0.0.3 worked fine. Adding branch verified keyword.
Keywords: verified1.8.1.3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: