Old bug, still not solved. linux 2000101113 Open mailcompose Select text equivalent of 4001 bytes or more in an external app Place cursor in mailbody field Click middle button Nothing pastes. In console it says "Read cliboard from memory" Now click middle mouse button again a few times: Console now states: ->>>>>>>>>>>>>> Read Clipboard from memory Don't know how to insert an image yet! -- Up to 4000 bytes can be pasted just fine this way. 4001 bytes ++ can not. 4001 bytes is barely a full page of text.

Reassign to akkana@netscape.com. I tried this with my Netscape_20000922_BRANCH Win32 and Linux builds, in both Composer and MsgCompose, and each time I was able to paste over 7K worth of data. I used the following script to generate a text file that told me exactly how many bytes I was selecting: #! /usr/bin/perl $str = "Now is the time for all good men to come to the aide of their country."; $len = length($str); for ($i = 0 ; $i < 100; $i++) { $total += $len + 7; # 4 digits, colon, space and LF. printf STDOUT "%4d: $str\n", $total; } I then loaded the textfile into emacs, selected all of it (7700 bytes) and then middle mouse pasted into both Composer and MsgCompose, and it always pasted properly. My trunk builds are not done building yet, I'll try them when they are done. Perhaps we need more info, like what window manager are you using, what app you are trying to copy from, and perhaps even the sample text you are trying to copy?

Cc jfrancis@netscape.com since he was involved in some recent copy/paste modifications.

I'm using gnome1.2 /sawfish 0.30 on RH6.2 all upgrades. The bug seems to occure regardless of what external application i have selected text in. Have tried from Powershell (xterm clone), tknotepad (simple Tcl/Tk editor) Abiword, gedit. It does NOT happen in NC 4.75, where i for fun tested pasting 3 MB of text, and it worked just fine. Sympthomatic is that the first patee attempt outputs "Read clipboard from memory" and the *second* attempt in addition states "Don't know how to insert an image yet". All subsequent attempts will now only state "Read clipboard from memory". The "image" error-message never displays again. This is not a new bug. It's months since i pointed it out, in connection with the same amount of text attempted pasted (over 4000 bytes) would crash mozilla. Also noteworthy: When closing the editor window (composer or mailcompose) - it does NOT prompt to save changes. Nothing is changed in editor by the failed pastes.

Ok, I see the problem now if I use gedit to load my sample file, and as you say, if you select more than 4000 chars it doesn't paste into composer. I'm wondering if gedit and the other apps you mention are using some X clipboard feature/type, when they have a selection greater than 4000 bytes, that we are not supporting in our code.

I forgot to mention that we might want to look at the differences in the X clipboard when it is set by emacs and when it is set by gedit, since we obviously support whatever emacs is using.

Also cc jst in case it's a noxif bug.

We'd better bring Pavlov into this. Pav, do you know of any limitations in the gnome clipboard which might be limiting copies to 4000 bytes?

Looks like a GTK clipboard issue. Over to pavlov.

Just wanted to add a note that there is no limitation on size for the clipboard ... I can paste *all* 7k of the text I selected in gedit, into a vi session, but not into Composer/MsgCompose. I think it has to do with us not recognizing the format of the data on the clipboard.

Adding akkana@netscape.com back to the Cc list.

the xincr protocol could be kicking in... although gtk does that for us, so we should be getting that done automagically.. I will take a look at this.

futuring... I know what is causing this, but the fix isn't trivial... maybe we can fix this for mozilla 1.0

The sum of futured bugs are by and by meaning that i can't use this product. I need a tool, not a toy. For the curiosity of it: Apart from emacs: Which applications CAN i paste more than 4000 bytes from?

I can paste 4900 bytes from nedit. Opening xclipboard and pasting into it first also seems to work. How about a description of the real problem? There's no reason to keep it secret, is there?

I really want to fix this. This bug angers me.

uncc'ing me

Hi, I noticed that this bug is still here in the latest nightly builds, any progress on fixing it since it really hampers me and I would guess a lot of other people. 4000 chars isn't that much, really :) AFAIK no gtk based app is able to paste into Mozilla, gedit other has mentioned but I can confirm that the same is true for Abiword too.

i don't have any problem pasting from gedit.. i don't have abiword, although i guess i could try it and see.

so.. does this depend on bug 84973? I still can't paste over 4000 byte to moz from any editor i use.

yeah, it pretty much depends on 84973.... we can't process the xincr messages that gtk tries to process because we have to process the clipboard requests syncronously...

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)

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

Please check Netscape 4.77 source, where this bug doesn't exist. See also [Bug 114968] New: paste of larger text impossible

Noone has mentioned it AFAI can see, but this bug affects pasting everywhere in Mozilla, not only in the Composer. *EXTREMELY* annoying and *EXTREMELY* counterproductive! RH 7.2 + all updates, GNOME 1.4, Sawfish 1.0.1, every Mozilla version I have ever downloaded. FWIW the bug affects Galeon as well.

Nominating for nsbeta1.

This is a Linux-specific bug. Is it actually the copy that truncates to 4000 bytes or the paste? Adding helpwanted keyword since I think pavlov wouldn't mind a patch from someone.

Copying > 4k from within Mozilla and pasting into Mozilla or into any other app works fine. Copying > 4k from any other app and pasting into Mozilla does not work.

clarify summary based on comment 27

brade: To clarify mair's comment with respect to your question, there is no truncation going on. Pasting just *doesn't work*.

This bug deserves some attention. It's quite a critical issue, since it gets in the way of such (for some people) critical things as good bug reporting (pasting stack traces) in Mozilla and derivatives.

Urm, comment 27.. Selecting more than 4000 characters in mozilla and pasting it in another app (wc -c in aterm) does not work for me, it just outputs one byte of a seemingly random value. So it does not work any way for me (from, to browser)

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

Ok, this is very very major bug that has existed for over two years. Please change this to "critical", as I'd like to see it fixed asap. And by the way, thanks for nice browser. :)

This bug is impeding serious wiki usage because non-trivial wiki contents can't be copied into another editor and then pasted back during editing.

Similarly, SpamCop is mostly unusable from Mozilla because of this.

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

not yet fixed in Mozilla 1.1b Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020722

Bug fix, cleanup and maybe speed up :-) I tested whatever came to my mind, and this just works for me. Only bugs remaining is interaction with KDE apps and sometimes the Paste option is not highlighted, but both of these existed before so separate bugs may (have to) be filled.

The patch is against Mozilla 1.1b source.

unfortunatly, you can't do that. the problem with this patch is that you also process other non-clipboard events. Too much code depends on the clipboard operation happening without other events being processed while it gets the data. This patch would introduce lots of hard to repdouce crashes and other problems. The "best" fix would be to make the whole mozilla clipboard interface async... but thats a lot of work. The other approach would be to rewrite the clipboard code to not use GTK and avoid using XINCR completly, since it doesn't really buy us anything since we have to block anyways.

Better solution to the problem. Rather than let go the entire main iteration, only filter clipboard events for the widget in question and process that. This works better and solves popup menu problems as well. There are some GTK warnings that I don't undestand: - some are clearly buggy (gdk_event_copy assumes that an event has always window and tries to add a ref, which is wrong) - when pasting by pop up menu, there are some warnings, look like random. I spent several hours trying to figure those out, but no success - maybe someone more skilled than me could help here. Other than those warnings, everything works great now :-) Again, the patch is against Mozilla 1.1b codebase.

This patch should also (help to) fix bug 83024 (I cannot measure that, though).

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

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

This is probably because we're using our own hand-rolled clipboard code instead of using the gtk code. If my memory serves, there's a specific protocol for handling large clipboard transfers.

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

Patch is needed ASAP. This bug makes mozilla unusable for most of content managment systems (CMS).

I've noticed that I can "paste" long text snippets into the e-mail composer, IF I SELECT THE TEXT from the HTML page. I could not find yet a size limit.. but if I select the text from the TEXT EDITOR (for example vi) I can not paste more than 4000 bytes just my 0.01 euro

ooooooooops I've forgot to say that my system is Mozilla 1.2b Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20020920

Mozilla's coding gurus , p l e a s e p l e a s e p l e a s e fix this booooooooooooooog ASAP

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

not yet fixed in Mozilla 1.3a Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021117

This is a very important bug. You should try to correct it before releasing any release.

Pasting maximum appears to be 1k, not 4. (Pasting 1025bytes causes the cursor in Mozilla to hang temporarily, 1024 works.) Verified copying from Vim (with select, and right mouse button paste) and Open Office (Ctrl+c/v). Running FreeBSD 4.7, XFree86 4.02 and Blackbox with Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021112 -E-

Clarification on comment #54 The 1K limit is only when pasting in to a text box in the browser (pasting to mail composer will paste upwards of 5120Bytes. So no probs there.) -E-

mgabriel: try requesting the review from a specific person... like blizzard

Now it's really time to fix this. Mozilla based clients are only possibility here with Linux, and this really really needs to be fixed. Do we have to pay some amount of money to the developers before they act or what might help? And somebody with enough power, please mark this as "blocker", I have not enough magic.

I don't think it's a blocker, but it does meet the terms of critical since there is dataloss.

Comment on attachment 93030 [details] [diff] [review] Better solution I told you guys one week ago that you should request review from someone specifically if you want results. doing that for you know.

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

Bug 190977 claims that the reverse doesn't work either (copying from Mozilla into another app).

yup, it (copy/paste to a different program) doesn't work for me (see comment 31)

Just a note (from my Dup 190977 ) - original xterm seems to work fine with any amount of data, rxvt and clones like aterm fail. What's curious though, where copying "mozilla to aterm" fails, "mozilla->xterm->aterm" works (no problem with copying large amounts of data from other than mozilla apps.) In aterm I get a single apparently random character pasted instead of no output at all as reported here. Sorry for dup, "selection" seemed to be the only reasonable component, wouldn't guess it's XP Toolkit/Widgets. (there's a few other clipboard-related bugs there) Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030121 aterm version 0.4.2 xterm: XFree86 4.0.3(156)

Quick note here ... while you could write your own clipboard code, you can't avoid supporting INCR. The sender side (the clipboard owner) is the party that decides to use INCR, and the ICCCM requires that you support it. I don't really understand what the big problem here is - yes, INCR requires reentering the event loop or scanning ahead for messages, but no more so than a normal cut and paste. I think someone just needs to read the INCR section of the ICCCM and extend the current bad hacks that mozilla is doing appropriately.

This bug is still alive on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030201. I have to copy and paste a lot of data from gvim into Mozilla (mainly in Insert->HTML of Composer) and this bug is being critical, because I have to divide the copyied text in 4 or 5 parts. Both clipboards have this problem (Ctrl-V and middle mouse button). The review is already 1 month old without any answer.

Workaround: 1) Open the file you want to copy using Mozilla e.g. in a new tab; 2) Copy it from within Mozilla where you want it. There's no limit on copying & pasting within Mozilla.

fyi, The patch doesn't apply cleanly anymore but it works! The only place of conflicts was in the header files inclusions and its not that big a deal. (Would it help if I posted a current patch?) There is one issue I noticed. After pasting it in the compose window, the window doesn't seem to get refreshed. So If I have a small compose window and paste a lot of text, the window stays blank. If I move the scrollbars around, the text shows up. Thanks mgabriel!

The patch makes opening composer hang for me. There should be some timeout checking somewhere, I think in GetTargets, and maybe others. Oh, and it doesn't use mozilla style everywhere.

no... select & paste still does not work !! I CAN NOT "select" in GVIM and "paste" into mozilla e-mail client more than 4K of pure ASCII text Mozilla 1.4a Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030315 This bug is more than 2 years old. Even MS fixes their bugs faster. This is "bug" is the only reason I am still using NS4.7X Messanger as my daily e-mail client. Please , please , please FIX IT !! Additional note: "select" & "paste" from NS4.7X browser to mozilla e-mail client (composer) works without a problem. I can select and paste with mouse any text I choose to. There is no size limitation.

This problem is made much worse by the fact that you can't paste more than 1K from Open Office and other apps to Mozilla. OO guys say it's a Moz bug, makes sense. http://www.openoffice.org/issues/show_bug.cgi?id=13235 Says: Cut/Paste maxes at 1K from Writer --> Mozilla* however much more is possible if you cut/paste from Writer-->Vim-->Mozilla. Why is this? * Cursor will hang in Mozilla form for about 1s, but no paste. (Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030409 RPT-HTTPClient/0.3-2) [...] ------- Additional Comments From Joost Andrae 2003-04-10 03:34 PDT ------- Joost: AFAIK this was a bug in Mozilla. Mozilla pretent to support the clipboard format text/html but it wasn't able to

Bug also visible when copying between different Mozilla instances. Nothing at all get copied. I tried to copy HTML (from HTML page composer to HTML mail composer). Using Moz 1.0.2.

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

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

This patch works well when copy data from OpenOffice, gvim, gedit with large data size. If the data can be transfered within 1 time, when requestor received "SelectionNotify" event, it means the data (if available) has been stored in the window's property of the requestor. But when transfering large data, INCR protocol is used. In that case, when requestor received "SelectionNotify" event, that only mean the data owner will begin to transfer data (refer to http://tronche.com/gui/x/icccm/sec-2.html#s-2). Mozilla thinks data transfer finished when received "SelectionNotify" event (refer to "FindSelectionNotify"), so large data copy failed. The solution in this patch refer to gtk2 implementation (see gtk_clipboard_wait_for_contents), which works well in Mozilla gtk2 version. BTW, OpenOffice has the same issue when pasting data, which cause the problem when copy from mozilla to openoffice. Hope OpenOffice guy can fix this issue. The limitation on data size is always 4K. Because when copy from mozilla to openoffice or from openoffice to mozilla, the data format is "text/html". So the data size we see is less than the size of actual data transfered.

Comment on attachment 125490 [details] [diff] [review] working patch Blizzard, can you spare some time to review this patch since this function is important and has been discussed for quite a long time ? IMHO, I think the solution is reasonable since it has been used in gtk2 implementation. Thanks very much.

I used to have problems pasting from nedit, but those are gone when applying this patch. However, when starting composer, it seems to hang now. the wait cursor stays forever, and i even closing all the windows doesn't quit mozilla anymore. Hmm, after more testing it works "sometimes". But i still can't exit mozilla cleanly. It seems to be waiting for some selection events.

I use mozilla1.4b on RedHat8.0 and don't encounter your problem. mvl, can you specify your building enviornment for me to reproduce the isse? Thanks very much.

I use regular nightlies from ftp.mozilla.org for regualr browsing, and sometimes pasting (even a few chars) doesn't work correctly. Mostly, that is from nedit into some html form. I have to try multiple times to get it working. My own build is with gcc3.3, debian prerelease and debug enabled, on debian testing. gtk is version 1.4.2. Opening composer hangs, but when switching to another virtual screen (or workpace, or whatever sawfish calls it) and switching back, stops the hang. But pasting is very slow now, and still unreliable. btw, with your patch and without DEBUG_CLIPBOARD, the build fails around line 477.

The output on the console when running mozilla -editor. nsPluginHostImpl::Observe "quit-application" is where i closed the window. It took a while before i got the prompt back, a few seconds.

This console output is from my workspace (mozilla trunk, RH8.0, gcc3.2, gtk1.2.10). The main difference with Michiel's is the time sequence of "quit-application" and "nsClipboard::WaitingForContents -> got reply and exit loop". With the patch, mozilla starts a new event loop when sending request. When getting "SelectionRecieve" signal, mozilla quit the new loop and return to the old one. From the debug info, there seems to be no problem when waiting for "SelectionRecieve" signal.

I test the patch on Solaris 9. With DEBUG_CLIPBOARD, it will crash sometimes because some debug sentence use "g_printf()", which can't handle "null" on Solaris (there is no problem on Linux), such as line 425. There is no crash without DEBUG_CLIPBOARD. If the speed of the running host is slow, it will wait for a long time when pasting both from mozilla and from other app (seem to hang, but really not). It's not due to Clipboard module. Getting data from clipboard won't cost much time. The delay happens after composer gets data. Besides the issues above, clipboard work well on Solaris9.

Comment on attachment 125735 [details] [diff] [review] updated patch for trunk can you use diff -u please?

same to previous one, using diff -u instead

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

I found the way to reproduce Michiel's problem. It happens in the circumstance below: 1. nsClipboard start a new main loop 2. nsClipboard start another new main loop before the SIGNAL come back(which mean the first new loop hasn't quit) 3. Only 1 SIGNAL come back, which cause the first new loop never ends. This only happen when GetTarget. So this patch only apply the new solution to "DoRealConvert", not to "GetTarget". Michiel, can you test this patch on your workspace? Thanks very much.

I did a quick test with the patch, and so far everything looks good. Al my tries to paste something succeeded (in the browser, in mailnews compose, and in composer), and quitting mozilla is no problem. I will leave the patch in my test build, and let you know when I see problems.

Comment on attachment 93030 [details] [diff] [review] Better solution clearing this review request as there are newer patches

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

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

Just to add my 2c: I'm running Firebird 0.6 on Mandrake 9.0 with KDE 3.0. I use ActiveState's Komodo text editor (based on the Gecko engine), it's based on the Gecko engine. I also found that I can't paste any sizable amount of text - more than about a page - between these apps. To get the text across I have to paste into KEdit or some other app, then copy again and paste into Firebird. Weird - especially since Komodo and Firebird are both Mozilla-based apps .. :S

> Weird - especially since Komodo and Firebird are both Mozilla-based apps .. :S This bug will happen when copy-paste between 2 running mozilla. So komodo and Firebird will also has this issue.

mozilla1.4 shipped. unsetting blocking1.4 request.

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

pav/blizzard, can we knock this one out for 1.5?

yes, I'll test this in the next day or two to make sure there are no extra problems

any update?

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

Too late for beta, not final material, -> 1.6a (with Stuart's consent).

Comment on attachment 126444 [details] [diff] [review] patch v3 I think this patch would introduce event reentrancy problems such as bug 214583 to the gtk1 port.

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

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

Bryner says he might know of a way to fix this without introducing the event reentrancy problems for GTK1.

This is an adaptation of the changes we made for gtk2 to fix this. The key change is that we must dispatch PropertyNotify events with atom == GDK_SELECTION to the clipboard widget in order for INCR selection retrieval to work. I also removed some unused code, including SendClipPing (which seems to be the only reason we were also processing ClientMessage events).

Comment on attachment 140213 [details] [diff] [review] backport of gtk2 patch If you're going to use select() you're going to have to use the code that's in XRemoteClient.cpp due to VMS differences. Just have a look there - you should be able to cut and paste.

bryner, we're going to be coming up on 1.7 Alpha pretty quickly (10 days). Is this the kind of change we should try to squeeze in for alpha, to get the extra release worth of exposure, or should we try to get it in first thing in Beta and have a full cycle of nightly builds to test?

Copy the VMS #ifdefs from xremote, and merge the same fix onto gtk2.

bryner: Is it possible that this has caused bug 233317 ("Cannot paste from clipboard")?

Please test with Open Office cut & paste. That's where it was most broken before.

I have tested pasting into Mozilla 1.6 and a build from yesterday on Linux. Pasting from OpenOffice.org doesn't work with 1.6 but does work with the new build. So, the patch works. Thanks for getting this fixed!

marking as fixed.

Comment on attachment 126444 [details] [diff] [review] patch v3 This is fixed, so I'm assuming this review request is obsolete.

Bryner: We should back this patch out. More and more people are complaining in the newsgroups and bugzilla (see bug 233317) that clipboard is now defunct and triggers crashes on all Unix platforms (I've seen reports for Solaris and HP-UX right now).

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

Bryner: This fix is poisened, please back this one out, it causes a regression on Unix builds (crashes on clipboard use), see bug 233317. Having a problem with more than 4000 bytes is not as severe as having a crash with a few bytes.

We need a volunteer on Solaris or HP-UX to reproduce this, work with bryner via IRC, and get it debugged. Roland, anyone? /be

Brendan Eich wrote: > We need a volunteer on Solaris or HP-UX to reproduce this, work with bryner > via IRC, and get it debugged. Roland, anyone? I can't help this week, still sick... ;-( BTW: There are at two Solaris 2.8 tinderbox machines at Seakmonkey-Ports ("worms" and "speedracer") which may be useable for debugging. Or ask timeless

brendan: no you don't. bug 233317 comment 29: > I'm not running CDE on Solaris and this problem persists until the other change is backed out. > This happens with Xvnc (not Xsun) and fvwm2.

timeless: try to say more than "no you don't", presumably in reply to my call for a volunteer on Solaris or HP-UX. I can trade cryptic bug comment references as well: http://bugzilla.mozilla.org/show_bug.cgi?id=233317#c33. You're not adding value here. We need someone who can reproduce the problem working with bryner to debug it, period, end of story. Lead, follow, or get out of the way. Carping inaccurately and cryptically doesn't help.. /be

There a problem with the "backport of gtk2 patch" <URL:http://bugzilla.mozilla.org/attachment.cgi?id=140466&action=view>: + int cnumber = ConnectionNumber(xDisplay); + fd_set select_set; + FD_ZERO(&select_set); + FD_SET(cnumber++, &select_set); ... + select_result = select(cnumber, &select_set, NULL, NULL, &tv); On Solaris, FD_SET() is implemented as a macro, and the first parameter is evaluated multiple times. So you're not allowed to use macro arguments with sideeffects (the ++ part of cnumber++), or you're getting bogus behaviour. (On Solaris, the connection to the X server is file descriptor 3, but we end up selecting on filedescriptor 4, which happens to be a DOOR file descriptor to the nscd server, and a DOOR cannot be used with the select/poll system call, so the select/poll always fails) After changing the code like this... + FD_SET(cnumber, &select_set); ... + select_result = select(cnumber+1, &select_set, NULL, NULL, &tv); ... the put&paste problems on Solaris seem to be gone!

That seems like a logical explanation, although I'm a little puzzled by the fact that the first argument is evaluated twice on Linux as well (at least on my Fedora Core 1 system).

This doesn't seem to cause any problems on Linux -- perhaps the Linux implementation of select doesn't care if its first parameter is too large.

The FD_SET testcase attachment reproduces the problem for me. When I compile it on Solaris using Sun's Forte compiler with optimization, the bit for FD 4 is set (*not* FD 3, as you might expect) % cc -O -o sel sel.c % sel bit for FD#4 is set i=5 Compiling the testcase with gcc and -O shows different behaviour: % gcc -O -o sel sel.c % sel bit for FD#3 is set i=5 Note that in both cases, the macro argument 'i' is incremented by two (and not one). It wouldn't surprise me if different gcc versions, or the same gcc version on different cpu architectures shows similar behaviour.

Comment on attachment 144051 [details] [diff] [review] patch to avoid ++ inside macro a=chofmann for 1.7b

Comment on attachment 144051 [details] [diff] [review] patch to avoid ++ inside macro Checked in to trunk, 2004-03-16 13:08 -0800.

Comment on attachment 144051 [details] [diff] [review] patch to avoid ++ inside macro And thanks to Jürgen Keil for figuring out the problem. (...who I forgot to cite in the checkin comment after chofmann told me to check in immediately.)