I see that on Mojave, disabling FinderSync extension from System Preferences doesn't actually disable the extension in Finder. The supposed-to-be-disabled extension still functions normally. I need to kill the Finder process or the actual FinderSync process to actually disable the extension in Finder. Is everyone else seeing the same behavior? If so, is this a bug or a feature? :) (I vote bug btw :)). On 10.13 and earlier it works the way you'd expect it to -- the extension is indeed immediately disabled in Finder.
Just speculating here, but are we supposed to use the 10.14 specific API showExtensionManagementInterface to do the disabling/enabling in Mojave? (https://developer.apple.com/documentation/findersync/fifindersynccontroller/3021184-showextensionmanagementinterface)
Thanks
Related
Question is what steps can I take to debug this?
It does very occasionally auto-save itself, but not on change of active window as previously. I can't yet reproduce a specific cause of this (very occasional) autosave.
I have all auto-save options as per default:
I recently did brew upgrade including fswatch. Would I be right in assuming IntelliJ would use its own though, not brew's fswatch if installed?
Another possibility is it's a Mac OS Privacy thing; a Catalina update seems to have broken one program which expected disk access to be available, now it's not; not sure if Intellij has lost some kind of OS permission to do (auto) saves(?), while this doesn't affect a user issued command to save, which works fine.
I'm trying to fix a couple of bugs for SafariDriver/Selenium.
Here is the problem:
On Safari 7 and bellow, to install a new plug in all you had to do is put the extension into ~/Library/Safari/Extensions. Next all you have to do is activate the plugin by adding it to the ~/Library/Safari/Extensions/Extensions.plist after this the Safari will have the plugin installed.
Starting with 10.10, this is no longer possible to do. The location of the extension is the same but i'm not sure how to activate the extension, since the Extensions.plist no longer exists.
My understanding is that there is some file that is controlled via "Safari Extensions List" password in the keychain under login but I have no idea which file this may apply to.
If I compile and install the extention by hand, everything works just fine but the automatic installation of the latest plugin is broken. (documentation for this https://code.google.com/p/selenium/wiki/SafariDriverInternals)
"Safari Extensions List" password is not password actually but a binary plist same as ~/Library/Safari/Extensions/Extensions.plist
Read it, modify it, write it back.
The correct thing to do is to have the user install the extension by opening it manually (double-click or command o). That's what Apple is trying to get you to do.
Apple never really wanted anybody messing about with plists for other apps.
Most preferences plists are cached in memory anyway and would require a new login session to blow them away and get new copies.
plists are updated on ending the session or the app in question.
They were never intended as a means to modify another app's behavior. That is a security risk.
In the case of Selenium, the intent is clearly to create an automated test environment. Setting up a nice installer pre-empts that to some degree.
The right thing to do is to file a bug with Apple letting them know what kind of functionality you need in Safari.
I can detect if my Opera extension installed by setting the new window object property (window.isExtensionInstalled for example) in injected script and checking it in web-page javaScript.
But this is not solution in case the extension is disabled.
How can I detect disabled extension?
Are there features like resources web-access in same manner as for Chrome extensions?
May be some other useful features?
Thanks in advance.
No, there is no such feature.
By definition, each extension lives in its own sandbox and is not aware of other extension.
The only chance is to look out of the window (object) and search for footprints (modifications of the window or child objects) of other extensions.
If these are forced to stay at home (deactivated), the can't leave footprints..
Sry for being so figurative ;)
I installed Uncrustify as per the instructions here:
http://noiseandheat.com/blog/2012/01/uncrustifying-objective-c-source-in-xcode-4/
Used brew for installation and added new behavior in Xcode(4.3.2) preferences.
However running the behavior from the menu does nothing. What might I be missing?
For me https://github.com/tonyarnold/Xcode-4-Uncrustify-Automator-Services worked : Automator is used to create a workflow, which will be available in Xcode to format the selected code (The link above could describe a better way - I am just saying what worked for me...)
Thanks Thomas, resource provided by you was very useful and allowed me to add automator workflows into Xcode. Only problem is that script "Uncrustify Document then Re-Indent" is showing an error "System Events got an error: Access for assistive devices is disabled". Initially I sudo touch /private/var/db/.AccessibilityAPIEnabled to enable assistive devices but this did not help.
I found a thread on similar issue here: AppleScript - System Events Error : Access for assistive devices is disabled
fanaugen says:
The problem is not the assistive devices. AppleScript seems to incorrectly return that error code when it tries to access windows of a process that can never have any windows
and he suggest to rewrite script with some changes. I am not sure if it is actually the same issue here and it's first time I am having to deal with this type of script, so I am lacking of knowledge here. Do you have any advice? Did you have a similar issue?
I have an old NPAPI plugin for OS X that I'm trying to refit for use with Snow Leopard's version of Safari. My problem is that when I switch Safari to 64-bit mode, it changes the plugin environment to out of process mode (where plugins are hosted by a 32-bit WebKitPluginHost process). And now my toolbar palettes are not visible on screen, even though the NSPanels on which they are based think they are visible. The documentation says that bringing up windows is not recommended, but doesn't say its prohibited; is there something I can do to bring up my Windows?
The most reliable solution is to simply let another application, possibly connected to your plugin via some IPC mechanism, do thatApple:
Avoid creating windows. The intent is for plug-ins to operate within the browser window. Although some plug-ins have historically done so, creating windows in your plug-in is not recommended. If you need to maintain separate windows, you should consider starting a separate application.
Bringing up windows from a plugin might work in some circumstances and completely break in different ones. By recommending against doing so Apple is at liberty to break your previously working behaviour whenever it wishes to.
Unfortunately, probably not. If you're doing anything that is not possible using the normal graphics libraries (CoreAnimation, Cocoa, etc), you probably can't do it using the 32 bit plugin in 64 bit safari.
You might be able to do more if you compile your plugin in 64 bit mode, though. I don't know :-/
I know I am a little late. Safari doesn't allow plugin to display NSPanel. You should try using NSWindow instead. I know Apple doesn't agree.
For showing menu you could use "popupcontextmenu". It takes NPNSMenu which is NSMenu typecasted.