I'm attempting to determine if my issue is unique to my installation, and to that end I'd appreciate some assistance from fellow users of OS X 10.6.8/Safari 5.1.10.

With Verizon DSL (if it makes a difference), e-mails created in Safari via command-i fail with this message:


The failures occur in all my e-mail accounts, I've verified my Mail settings with Verizon (Nope! Their tech had absolutely no idea what may be up...wasn't even familiar with the command-i functionality.), and I've not experienced a single other e-mail glitch of any sort since this has begun happening, which, I think, was when I updated to Safari 5.1.10.

Thanks for any help.

That's me and, like your Verizon tech, I was unaware of the Command-i functionality.

I just ran a quick test. Command-i brought up my Apple Mail with this page in the body and the Subject of the email was "Help, please! :)". I sent it to myself and it both went and was received without incident.

Thanks, ryck; I was afraid of that.

I hope somebody can come up with something, because I couldn't even get close to the question, let alone the answer, with Google.

I too was unaware of the Command+i trick, but I just tried it and duplicated ryck's results in Safari 7.0. I have thought of some tests you might try to see if they effect your results.

• I presume the results are similar on other sites?
• Have you tried using another email host such as Google?
• Have you tried turning off Safari extensions?

Do you have the problem if you log into a test account?

> Have you tried turning off Safari extensions?

Bingo!

For the second time today, same as in deniro's thread, the culprit is the "EasyList" filter in my outdated version of AdBlock.

Many thanks!

(Gotta start thinking in a new direction when the question is "Safari?")

Edit: I guess I now owe everybody an explanation of why I refuse to update my version of AdBlock, so...

In its early incarnations, AdBlock included functionality that allowed users to block any element in an html page, the FTM masthead by way of example, and I loved the idea that I could block all the annoying proprietary stuff on the Web pages I visit regularly.

Through the version I'm running, v 2.1.5, the "block pane" was invoked by either hot key or contextual menu, and when the hot key disappeared in v 2.1.16 I stopped updating.

Just to see what's going on, though, I've tried updating to the most recent version, and as far as I can tell, the html blocking functionality is gone...BOO!!!

So unless somebody can tell me that I'm missing something (not too obvious, I hope), here I sit.

I'm at a loss, though, as to why the "EasyList" filter does not work similarly in both early and current versions of AdBlock. (Time to e-mail the dev, I guess.)

Edit 2: I've found that the functionality is intact, but its implementation has changed, and I don't know if I can easily transform what I've got into what I need (if I actually choose to deal with the hot key deletion). (Awaiting dev response.)

Good question, but joemike beat you to the punch by suggesting extensions as the possible cause of my problem.

where is that in the mail menu? I'd always thought that command keys triggered menu options, and therefore it must be in the menu somewhere, but i don't see it?

command-I is a Safari option, found under Safari > File.

I'm referring to the cmd-i behavior in mail.app

No such functionality was mentioned in this thread; ryck's post referred to Safari's command-I functionality that I questioned in my opening post.

Nonetheless, it is curious that ⌘-i does produce an action in Mail, even though, as Virtual points out, there appears to be no corresponding menu command.

Your post got me laughing and looking, because I've used command-i in Mail on innumerable occasions without ever having looked to see what is or isn't in the menu bar.

So here's the deal: command-i actually has two functions in Mail 4.6:

1. When I'm composing an e-mail, it toggles italics.
2. When I'm not composing, it calls up an "Info" window from which I can delete e-mails from my POP server.

And the command does appear in Mail's menu bar, but only once (that I can find), here .

Thanks for the push.

Edit: I've been meaning to post this, and now is an appropriate time: Coming around full circle, it turns out that command-i looks like it's got two functions in Safari, too, here , and here , but it doesn't toggle my toolbar; I can only do that from my menu bar.

speculating… in the debug menu in mail? I assume it has one like many other os x apps (disk utility being the most useful perhaps) but I don't recall a debug menu in mail.

About what are you speculating? It's not at all clear.

is the "edit pop account messages" window an option in a hidden Debug menu similar to the one in Disk Utility?

That looks like ⌘| [shift-pipe, or shift-command-backslash] to me, not ⌘I. I can't test that theory, because that combo in Safari 6 is assigned to the Show All Tabs command (where, interestingly, it's displayed as ⇧⌘\)*; there is no keyboard equivalent for Show/Hide Toolbar.

*If my theory is in fact correct, then the display of the keyboard equivalent in the View menu in your version of Safari is inexplicably inconsistent with Apple's policy of including the ⇧ in combos requiring the shift key. (Also inconsistent, but from the other direction, is ⌘+ for Zoom In; I guess the intuitive pairing with ⌘- for Zoom Out overrides literalism in that case, since ⌘= is really the combo being used.)

It's not an option I remember having enabled on my own, and if Mail has got a debug menu, I'm unaware of it.

Sorry, I've got absolutely no idea when or where I learned the trick, but I can say that I've been using it for years. (I mentioned POP, because that's what I use; I think the window also works for IMAP.)

Edit: I just looked in my plist to see if there was a relevant entry, and he only thing I found was


("Account Info" is the heading in command-i windows.)

Your theory is, indeed, correct. Thanks!

| and I are so similar looking, and I use pipe so rarely, virtually never, in fact, that the difference between the two didn't register; Apple's having used ⇧⌘\ would most certainly have been the intuitive thing to do in this instance.

And I've always wondered why Safari's menu shows ⌘+ for "Zoom In" when ⌘= works just fine...totally unintuitive.

(Hmmm... Now that you've mentioned it, I think I actually raised the | v I issue before; I hope it's burned into my brain this time around.)

I just re-ran my original test..........


........and the results were exactly the same.

With the mention of Command-l in the thread, I did another test and found that issuing that Command-l using the keyboard does nothing.

However, my Safari File shows Command-l as the keyboard equivalent for "Mail Contents of this Page".

And, if I go to File and select "Mail Contents of this Page", I get the same result as typing Command-i on the keyboard.

So it appears that it's Command-l in one place but Command-i in another.

> With the mention of Command-l in the thread, I did another test and found that issuing that Command-l using the keyboard does nothing.

Sorry, ryck, I don't follow you.

What is the character that follows command- in the above quote? (It looks like an l.c. L, which has not been mentioned in this thread.)

Command-u.c. i opens a new e-mail with a link to the Safari page at which I'm looking.

Actually I suspect that's how it works.

think about screen capture. shift-cmd-3. by the above they could have instead said cmd-#

the 3 (or in your case the =) refers to the key on the keyboard, not the character it produces. If it's shifted, it's still the 3 or the = key. the shift must be stated explicitly, and so the key is stated as un-shifted.

Though it's interesting to note that in that specific instance, cmd-= and cmd-+ both work. I wouldn't have expected it to work. Perhaps the shift is optional and acceptable if no other combo uses it.

I think you're on to something there, because cruising Safari's menu items reveals that every command that incorporates ⇧ also includes a letter that's displayed as u.c. despite the fact that the command's intention is l.c.

And further, commands that incorporate signs/symbols lack ⇧ because they're readily identifiable as requiring ⇧ if it's necessary (8/* by way of example), "pipe" being an exception, because it's so easily confused with "I".

And as you pointed out, the +/= thing is an anomaly.

shift is probably only necessary where there are two menu options that are the same except for shift. in other cases, the shift is probably unnecessary but acceptable.

this may be true of other modifier keys as well.

I tested it in activity monitor because it's relatively sparse on command keys, and found that cmd-1 to open the activity window would merely bonk with any other modifiers held (shift, ctrl, or option) so guess not. They must have coded mail to allow shift also even though there's no clear indicator. They may have accomplished this via a hidden menu item, because programmatically (within their public frameworks) I don't think it's possible.

The letter is in upper case (probably) because the keyboard's key caps are all upper case.

Have you ever seen a menu command that includes a letter which is not displayed as upper case?

That's a very good point. If the menu command displayed a lower case letter, like "⇧f" you can bet that people looking at their keyboard would say there is no "f", I only see "F".

This is similar to the instruction: "Push any key. Where's the 'Any' key?"

Edit: Sorry for taking so long to respond.


By implication, yes, on my OS X Install and Apple Hardware Test discs where it says "hold down the C or D key", respectively, and in several similarly worded Apple docs. (Somebody at Apple apparently recognizes that "X" is ambiguous in the context of a keyboard command.)

And in response to Ira, that ambiguity could just as easily lead people to depress the shift key when it's unnecessary, or, possibly worse, when it will produce unwanted results.

And further muddying Apple's consistency is the fact that control and option are represented by ^ and ⌥, which have absolutely nothing to do with the appearance of their respective keys.