danny0838 / firefox-scrapbook

ScrapBook X – a legacy Firefox add-on that captures web pages to local device for future retrieval, organization, annotation, and edit.
Mozilla Public License 2.0
323 stars 65 forks source link

[Req] cmd key support for Mac #108

Closed pascallothar closed 8 years ago

pascallothar commented 8 years ago

I have read in the manual of the legacy Scrapbook [http://www.xuldev.org/scrapbook/tips.php]:

I am on Mac Os X Snow Leopard 10.6.8 on a MacBookPro, so I have no middle-click. Ctrl key behavior on Windows is usually operated by the Cmd key on Mac.

When I click on a item in the Scrapbook_X Sidebar with Cmd key down, it does the same than without the Cmd key, it opens the item in the current tab. This behaviour is not consistent with the usual behaviour on Mac and should open the item in a New Tab. And, so, I make often mistakes and open the item in a tab where I was doing some editing ... which goes lost.

Could you please implement the right behaviour for Mac or, at least, the possibility to choose it from the preferences?

danny0838 commented 8 years ago

I have never used Mac. According to several documentation, it seems that in the browser it is Mac Control key that acts like Window Ctrl key. Could you try Control+Click and see if it works?

danny0838 commented 8 years ago

Additionally, could you test whether legacy ScrapBook (current 1.5.13) work on Mac?

pascallothar commented 8 years ago

Hello, I was wondering if I misled you, so I was googling a little bit to remember how it works on Windows and Linux. Probably the documentations you mentionned were talking about the mapping of the keys themselves of the PC keyboards and the Mac keyboards (meaning hardware), but not about their functionality on the different operating systems.

For example, to copy on Windows, you will use ctrl + C, where you will use cmd + Con Mac.

[http://www.howtogeek.com/183636/how-the-command-and-option-keys-work-on-a-mac/]

On Mac,Ctlr + Click has everywhere the same behaviour than right click (probably because the earlier Macs had a mouse with only one button (meaning only the "left" click button)).

In [http://apple.stackexchange.com/questions/170731/how-to-open-link-in-a-new-tab-via-shortcut-in-chrome-on-mac]:

Cmd⌘ + Click will open a link in a new tab behind the current one, if you click a link. Cmd⌘+ Shift⇧ + Click will open the new tab & bring it to the front.

Those two behaviors applied to a Sidebar Item would be consistent with the usual Mac behavior. For the moment, Cmd + Click doesn't do more than Clickalone, and, as I said, is prone to "mistakes".


As you can see, Mac wouldn't have been Mac if they had done things easier and had followed the behavior of others :-)

pascallothar commented 8 years ago

I have just installed ScrapBook 1.5.13.1-signed.1-signed (Gomita) on my MacBookPro with MacOsX 10.6.8 (last Snow Leopard).

Everything seems to work. Though I didn't test it thoroughly.

"Create MAF" (your add-on version) on a Sidebar Item does NOT work. "Copy Page Info" (your add-on version) on a Sidebar Item DOES work, BUT does NOT work on the full tree (Sidebar -> Tools -> Add-on functions -> Copy Page Info: Arborescence complète).


Disabling Scrapbook, re-enabling Scrapbook X :-)

danny0838 commented 8 years ago

Could you please check first whether control+click work on Mac? Likeweise, please also check whether control or cmd work on legacy ScrapBook? If possible, check a few more ctrl usage cases mentionerd in the documentation you provided so that we can make sure wehether it's general case or not

pascallothar commented 8 years ago

Hello Danny,

1°) It seems that I didn't understand why you asked me to try the legacy Scrapbook on my Mac. I thought it was to help you to know if it was working or not on Mac, but, now, I have understood that it was to know its behavior with the Cmd and Ctrl keys. :-)

2°) I said: « I was wondering if I misled you, so I was googling a little bit to remember how it works on Windows and Linux ». I was not sure that I was remembering well the behavior on Windows and Linux, but I was sure of the behavior on Mac, since I use these shortcuts everyday :-) . (And also, I didn't change the default behavior). I remember it was a little bit annoying in the beginning when I migrated to Mac.



1°) The default behavior on Mac for Ctrl+Click (system wide) is to open the contextual menu (Same behavior than if you have a mouse with a right-click (the earlier mouses branded by Mac had only one button)).

For Firefox, TabMixPlus allows you to change the behavior of Ctrl+Click from a°) the default contextual menu; to b°) force opening in the current tab the stuff (depending on the other settings) that should open in an new tab.

There is no possibility to change the other behaviors of the key shortcuts like Cmd+Click or others from the Options set-up (perhaps is it possible with about:config?).

One of the two links I gave you [http://apple.stackexchange.com/questions/170731/how-to-open-link-in-a-new-tab-via-shortcut-in-chrome-on-mac] is for Safari on Mac (the question was asked for Chrome on Mac, but the answer was mistakenly given for Safari on Mac). On Safari, you can change the default behaviour (but it will always use Cmd (actually, you will only toggle new tab / new window in new window / new tab and background tab / active tab in active tab / background tab)), not on Chrome (perhaps if you edit the config files?). In this link, you will see: « Cmd + Alt + Click = Opens a link in a new window » and « Cmd + Alt + Shift + Click = Opens a link in a new window, and makes it the active window », but it is SPECIFIC to Safari. BUT « Cmd + Click = Opens a link in a new tab » and « Cmd + Shift + Click = Opens a link in a new tab, and makes it the active tab » are common to Firefox, Chrome, Opera (I have never used Opera before, but I have just installed it to check the behavior) and are not configurable and are the DEFAULT behavior of Safari. They sey also « Remember that Cmd⌘ on Mac is usually equivalent to Ctrl^ on Windows »; I can say that, yes, it's USUALLY true.

Here is an other link [http://www.7is7.com/software/firefox/shortcuts.html] with the shortcuts for Firefox 3.5 and 3.6 for the three major OS. You can see there (and I can confirm it) that on Mac OS X:


2°) I will also make you the description of the behavior of the "Finder", of other file explorers or the like.

See my comment (#23 ).


3°) I have tried again ScrapBook 1.5.13.1-signed.1-signed (Gomita):

a°) In the Sidebar (Gomita):

b°) In the "Manage" window: (actually the behavior is the same than in Scrapbook X):


4°) Now to compare with Scrapbook X (Version 1.13.0b4):

a°) In the Scrapbook X Sidebar: (the differences with Gomita's are in bold italic):

b°) In the "Manage" window:

Same behavior than in Gomita's Scrapbook.


5°) In the Firefox bookmarks window:


6°) I wonder if, this night, I will dream of:

Or ... of all of them mixed together? :-) Sure, it will be the ... right click! :-)

danny0838 commented 8 years ago

In both references on the Mozilla Developer Network and W3school, it is a standard that a mouse event with metaKey = Win key on Window = Command key on Mac. There is no specific documentation talking about ctrlKey, but I think it is Control key on Mac since Command key is used by metaKey.

Maybe it's custom that Mac users use command as Ctrl in Windows, but it already a standard that in the browser javascript system it's Command = metaKey = Win key. We don't know why the standard is formulated in this way, but we have to add many additional codes and ac hoc handlers to do the remap for Mac to work use Command key as Ctrl.

Here are still something we need to know:

  1. Is Control key on Mac naturally work as a key for context menu?
  2. Could you try the hotkeys for DOM erasor and for HTML editor and see whether Command or Ctrl key work? (Open a captured page, and you can see DOM erasor and HTML editor buttons in the editor toolbar. Hotkeys for DOM erasor are listed when you activate the DOM erasor. Hotkeys for HTML editor is shown in the context menu when HTML editor is activated )
  3. Could you help me check an Firefox config on Mac? Type about:config in the address bar, and find the value of ui.key.accelKey.
danny0838 commented 8 years ago

@pascallothar On 1.13.0b8 we implemented a new hotkey system to support cross-platform issues. Welcome to try whether command key work as expected and whether hotkeys are showed in Mac style.

This is the hotkeys shown on most platform: screenclip

This is the hotkeys ought to shown on Mac if it works right: screenclip 1

pascallothar commented 8 years ago

The answers are for your TWO posts:



In both references on the [Mozilla Developer Network] and [W3school], it is a standard that a mouse event with metaKey = Win key on Window = Command key on Mac. There is no specific documentation talking about ctrlKey, but I think it is Control key on Mac since Command key is used by metaKey.

Maybe it's custom that Mac users use command as Ctrl in Windows, but it already a standard that in the browser javascript system it's Command = metaKey = Win key.

Yes, you are right:


Maybe it's custom that Mac users use command as Ctrl in Windows, but it already a standard that in the browser javascript system it's Command = metaKey = Win key. We don't know why the standard is formulated in this way, but we have to add many additional codes and ac hoc handlers to do the remap for Mac to work use Command key as Ctrl.

        Yes, the lack of coordination and of standardization is a nightmare for informatics (and for the world in general (kind of Babel tower)).         As I understand things from the stuff I have read in the past (and today), Shift was already used by typewriters; Ctrl (as its name stands for), Alt, and other control keys and control characters were used by the teletypewriters, the terminals, the terminal emulators and the earlier keyboards of different electro-mechanical, electrical or computer systems. Xerox begun the GUI operating system, followed by the Apple Macintosh, followed by Microsoft Windows. They reused features of the legacy systems, but they were following their own way of doing things. The portability of the applications was not their preoccupation at that time. As for the war of document and media formats that happened at those times, the war between Mac and Windows was not to ease the standardization, which occurred much later because of the needs of industry. Fortunately, nowadays, a lot of the most common shortcuts have perhaps a different modifieR key, but the modifieD key is the same. Imagine if Mac would use Cmd+Q, Linux Ctrl+D and Windows Ctrl+C to copy. We could of course imagine worse: that the British oranges would be American bananas and that British bananas would be American oranges. Or that the words "on" and "off" would have inverted signification in the two countries. Yes, it's almost that with the Cmd and Ctrl behaviors :-) .


Is Control key on Mac naturally work as a key for context menu?

        No. Ctrl on Mac, as on Windows, is a modifier key, meaning that if you push it alone, nothing happens (USUALLY, to be precise! Because some rare applications will use a modifier key as a simple key (hitting once or twice Alt (or and other modifier) or keeping it pushed more than 2 seconds for example), but I don't remember any example for the moment. It is also possible to use a simple key as a modifier (for example, when Space is down, hitting K). Actually, this is not specific to Mac).         But Ctrl+Click is the equivalent of Right-Click (As I said above and in other posts, Mac used GUI and mouse with only one click before MicroSoft created Windows, so, the contextual menu was triggered by Ctrl+Click. Only later, Mac introduced a "Secondary Click" (name of the right-click in the Mac world, probably to not use the same word than Microsoft)).         Besides Cmd and Shift, Ctrl and Alt are used for shortcuts also, but they are not so many than the shortcuts build with Cmd == Meta. [Mac keyboard shortcuts https://support.apple.com/en-us/HT201236] will give you the shortcuts used system-wide and also the shortcuts used by the applications branded by Mac and integrated in their distribution. The third party applications will try to mimic the behavior of the Mac "integrated" applications (e.g.: Firefox shortcuts are usually the same than Safari's (Mac "integrated" web browser)).


Here are some links concerning what I said above in the present post:


Could you help me check an Firefox config on Mac? Type about:config in the address bar, and find the value of ui.key.accelKey.

ui.key.accelKey == 224


In the "Version History":

Functionality changes:

  • Improve cross platform hotkey support, especially the command key support and the key symbol style for Macs.
  • Allow customized hotkey combination in the user options.

I don't see that in the Options GUI? Is it in a configuration file, then?


.../... and whether hotkeys are showed in Mac style. .../... This is the hotkeys ought to shown on Mac if it works right:

No. Here is what Mac users ACTUALLY see:

html_editor_mode_contextual menu

For me and aware people :-) , it's not a problem, but very probably, most people would have no clue of what Meta is!


Could you try the hotkeys for DOM erasor and for HTML editor and see whether Command or Ctrl key work?

First is the test with 1.13.0b7:

DOM Eraser:

HTML Editor:

Now is the test with 1.13.0b9:

In the Options dialog, "Show the Sidebar" == Alt+K works. The newly implemented "Menu" == Alt+C does nothing. Which "Menu" is it?

DOM Eraser:

HTML Editor:


As you can see, you had a good idea in allowing customized hotkey combination in the user options.


NOTE: I didn't say that it is bad to use Ctrl on a Mac, but that:


Would it be difficult to implement some Help pop-up in Scrapbook X HTML Editor mode (I would say with shortcut Cmd+?) like the one in Scrapbook X DOM Eraser mode?


I have looked up the usage of shortcuts in different HTML editors on the Mac OS X platform (iWeb, Komposer, BlueGriffon, Adobe Brackets, Adobe Dreamweaver, SeaMonkey Composer, Amaya). There is no real standard usage, only some canonical common shortcuts and some others poorly shared (As you can see once more, you had a good idea in allowing customized hotkey combination in the user options). When I will be able to access the "customized hotkey combination in the user options", I think I will choose (But I don't say it is the best or the only way to make a default usage on Mac. I believe that people would choose according to the app they are used to work with) the following customization (so, I give it only for simple info):


I hope it will help you. Pascal

danny0838 commented 8 years ago

@pascallothar We need your help to get it work right.

Please download and install the .xpi file in this test version (you probably have to set xpinstall.signatures.required to false in the "about:config" to make it installable on your Firefox). If it work correctly, an alert window will prompt and report your OS when you restart your Firefox like this:

sp160730_222534

Please report the text content or the screenshot image. We need this information to fix the OS detection issue on Mac.

If you have multiple Mac notebooks in different versions, please try all of them as possible.

pascallothar commented 8 years ago

I have only one Mac: It's a laptop: MacBookPro with Mac OS X 10.6 (also named "Snow Leopard"), 10.6.8 precisely.

for_danny

xpinstall.signatures.required to false was already needed to install 1.13.0b7 (or b5 or something, I don't remember)

Question: I suppose that you DID know that Scrapbook X DID already detect Mac (because it was using Cmd key in the Manage window). Didn't you? I prefer to tell you it, to avoid you extra-work.

danny0838 commented 8 years ago

Here is the second test version. Please check:

  1. Whether key names are shown in Mac style on Macs.
  2. Whether the default behavior of shortcut keys are still not skipped. (e.g. right-click isolate for DOM Eraser shows a context menu)
  3. Whether customization of HTML editor shortcut keys via the options dialog works right.

Notes:

  1. When HTML Editor mode is on, Ctrl+A (Select all), Ctrl+C (Copy), Ctrl+X (Cut), Ctrl+V (Paste), Ctrl+Z (Undo), Ctrl+Shift+Z or Ctrl+Y (Redo), etc, are already provided natively by Firefox. Please check whether they actually work or not.
  2. We probably cannot solve the issue that system wide hotkeys overwrites our hotkey since systemic hotkey takes precedence. The only way is to modify the system hotkey or to modify our hotkey to prevent a conflict.
pascallothar commented 8 years ago

Whether key names are shown in Mac style on Macs.

Yes, now, they are. Actually, the + sign between the keys are usually not print, but IMHO, it doesn't matter.

cmd z greyed out

a main

b text

c block

d insert

e advanced



Whether the default behavior of shortcut keys are still not skipped. (e.g. right-click isolate for DOM Eraser shows a context menu)

Actually, except for (1) and (2) below, everything is OK.

DOM Eraser

Nothing else have changed since 1.13.0b9 (see in the post above for the detailed feedback). So, in 1.13.0b9.2-shortcuttest:

HTML Editor

All the others things were already working the way expected to be.



Whether customization of HTML editor shortcut keys via the options dialog works right.

The default size of the Options Dialog is different than it was. It's totally collapsed for several tabs, but, because I was able to resize it, it is OK. But, for the tab of the shortcuts, I couldn't access all the shortcuts, because the dialog would need more height than my screen. So I would need to find on my disk the Scrapbook X configuration file and edit it by hand. But I didn't find it. Here are screenshots of the Options Dialog.

I have edited the hot-keys in the 2nd tab. They don't update in the contextual menu nor do they update in their behavior. So I restarted Firefox. Now it works.

For the inaccessible hot-keys and for those of DOM Eraser, I have tried to find a config file, but I could not find it!



When HTML Editor mode is on, Ctrl+A (Select all), Ctrl+C (Copy), Ctrl+X (Cut), Ctrl+V (Paste), Ctrl+Z (Undo), Ctrl+Shift+Z or Ctrl+Y (Redo), etc, are already provided natively by Firefox. Please check whether they actually work or not.

Yes, they work (Cmd for Mac of course).



We probably cannot solve the issue that system wide hotkeys overwrites our hotkey since systemic hotkey takes precedence. The only way is to modify the system hotkey or to modify our hotkey to prevent a conflict.

Actually, it is not even desirable that system wide hot-keys would be overridden. I was only making a complete feedback of the behavior for a better understanding. And to report that some hot-keys chosen by Scrapbook were already taken by the system. And since the hot-keys are now customizable, it should not be seen as an issue anymore.



On the page of the current version, I see:

Customizable DOM Erasor shortcuts. (Only via user perference)

I cannot find out how to customize them. What and where is this "user preference"?



The newly implemented "Menu" == Alt+C does nothing. Which "Menu" is it?

Actually, in "HTML Editor" mode, it writes only ©, which is the default behavior if there is no shortcut defined.

danny0838 commented 8 years ago

I cannot find out how to customize them. What and where is this "user preference"?

It means Firefox user preference, which are all available in about:config, and some of them are available in the GUI options.

Note that the user preference uses the normalized string which could be different from the GUI. If you don't know how to write, you can set a few key combinations (e.g. Show in Sidebar) in the GUI and see how corresponding user preferences (e.g. extensions.scrapbook.key.sidebar) changes in the about:config.

We do not provide the GUI way because we do not encourage a modification on DOM Erasor keys.

Actually, the + sign between the keys are usually not print, but IMHO, it doesn't matter.

We'll adjust the accesskey text to be more compatible to Mac style.

Right-Click will isolate, but will also open the "contextual menu". (2)

Please check about:config and see whether dom.event.contextmenu.enabled is set to false. This will block any attempt to block the context menu from showing up so a right click always shows the context menu.

I'm not sure whether Control+Click is also affected by this setting. You can also test it for Control+Click issues.

On my MacBookPro with a FRENCH keyboard layout, if I want to write a + , I need to hit Shift+= (= with Shift down) or Caps_lock+= ...

If your keyboard has key = that outputs + with Shift hold, it is simply = or Shift+=, which is never equivalent to + for the accesskey system.

Similarly, if your keyboard has a key = that outputs + when CapsLock is active, it's simply = for the accesskey system.

But we are somewhat lazy. When the DOM Eraser says + and -, it actually means Numpad+ or Shift+= and Numpad- or - (hyphen-minus).

  • As said in the post above, - was working perfectly in version 1.13.0b7.
    • But in version 1.13.0b9, it was working as a normal key (not anymore as a hot-key), meaning that it will open the "Find in the page ..." bar with - written in it.
    • Now, in 1.13.0b9.2-shortcuttest, it works the same (wrong) way as it was already working in 1.13.0b9. (1)

Please check what keys are actually pressed when you mean - on your keyboard. Is there a modifier?

And please also check the about:config and see whether accessibility.typeaheadfind is set to true. This determines whether a key fires a search, and it seems to block certain accesskeys from working in some unclear situation.

But, for the tab of the shortcuts, I couldn't access all the shortcuts, because the dialog would need more height than my screen. So I would need to find on my disk the Scrapbook X configuration file and edit it by hand. But I didn't find it. Here are screenshots of the Options Dialog.

I really have no idea why it works so on your computer. All option tabs are written in the same way and there should be scrolls for the hotkey tab just like other tabs do if it works as expected:

dialog

A guess is that it will work so if the total contents overflows your screen, which is ought not to. If it really does, it may be a bug of Firefox.

Could you check whether resizing the dialog window works? And whether mouse scroll has an effect?

Additionally, hotkeys for HTML Editor are also user preferences and are available in the about:config. You can set them there if the GUI is unavailable for any reason.

danny0838 commented 8 years ago

Here is the third test version. Please check:

  1. Whether the Mac style hotkey text work right.
  2. Whether the scrollbar works in the options panel if the content overflows the dialog window.
pascallothar commented 8 years ago

Please check about:config and see whether dom.event.contextmenu.enabled is set to false. This will block any attempt to block the context menu from showing up so a right click always shows the context menu.

dom.event.contextmenu.enabled == true If I have well understood, it is the right value. Isn't it?

I'm not sure whether Control+Click is also affected by this setting. You can also test it for Control+Click issues.

Could you be more explicit?

On my MacBookPro with a FRENCH keyboard layout, if I want to write a + , I need to hit Shift+= (= with Shift down) or Caps_lock+= ...

If your keyboard has key = that outputs + with Shift hold, it is simply = or Shift+=, which is never equivalent to + for the accesskey system.

Similarly, if your keyboard has a key = that outputs + when CapsLock is active, it's simply = for the accesskey system.

But we are somewhat lazy. When the DOM Eraser says + and -, it actually means Numpad+ or Shift+= and Numpad- or - (hyphen-minus).

Thank you. It helps me to better understand how the French keyboard layout works.

Indeed, by playing with the customization fields, I can see that, on my keyboard, even if I have to hit ( with Shift down or ( with Caps_Lock to write a 5, the customization field will be filled with 5 when I hit ( with or WITHOUT Caps_Lock.

Meaning that I will never be able to define a shortcut Alt+( (to replace Alt+[ which is not accessible with my keyboard), but only Alt+5 (that is already used).

But Alt+) is possible () with Shift down writes a °).

Meaning that the mapping of the French keyboard layout to the "access-key system" use sometimes "uppercase", sometimes "lowercase", and that independently of Caps_Lock.

  • As said in the post above, - was working perfectly in version 1.13.0b7.
    • But in version 1.13.0b9, it was working as a normal key (not anymore as a hot-key), meaning that it will open the "Find in the page ..." bar with - written in it.
    • Now, in 1.13.0b9.2-shortcuttest, it works the same (wrong) way as it was already working in 1.13.0b9. (1)

Please check what keys are actually pressed when you mean - on your keyboard. Is there a modifier?

No, no! No modifier. It is the hyphen-minus.

extensions.scrapbook.key.domEraser.narrower3 was set to Hyphen_Minus. I have deleted the _, setting it to HyphenMinus. Now it works again (as it did in 1.13.0b7).

Are you sure that it works on your Windows with the string Hyphen_Minus (with _)? If it does, Steve Jobs (or somebody else, probably) needs some posthume ears pulling :-) to learn not being different uselessly.

And please also check the about:config and see whether accessibility.typeaheadfind is set to true. This determines whether a key fires a search, and it seems to block certain accesskeys from working in some unclear situation.

accessibility.typeaheadfind == true

Actually the key fires a search only if it is not defined as a hot-key, so it should not be a problem. As said above, - was not defined because the string Hyphen_Minus was not recognized as -.

Here is the third test version. Please check:

 1. Whether the Mac style hotkey text work right.

Yes, it works right. Here are the screen-shots.       menu1

menu4

menu3

menu2

 2. Whether the scrollbar works in the options panel if the content overflows the dialog window.

Sorry, nothing have changed.

Could you check whether resizing the dialog window works? And whether mouse scroll has an effect?

  • Resizing works.
  • Mouse scroll works only when the scroll bars show up (which is not an unexpected behavior LOL).

I wonder if it is not related to the pre-defined values of the minimum and maximum size of the scroll bar. If the blue bar-cursor of the scroll bar is to high, the minimum size of the window has to be too high for the height of the screen. Setting the height of this blue bar-cursor to a lesser value (If it possible to do that?) should do the trick.

Why do I think that? Because the "Edit" tab needs almost the full height of the screen and when I resize it a little bit less high than the screen I can not see all the content of the tab anymore (even by scrolling).

Actually, even for the tabs with a small height (like the "Tabs" tab), the behavior is the same.

Here are the screenshots.

tabs tab just big enough to show everything when scrolling

tabs tab not enough height to show everything even when scrolling

keys tab full height

keys tab full height and less width

edit tab before resizing

edit tab full height

edit tab full height but less width

edit tab less height and less width

Additionally, hotkeys for HTML Editor are also user preferences and are available in the about:config. You can set them there if the GUI is unavailable for any reason.

OK. I have used that as a work-around. Actually, even if the GUI is of course more convivial, we don't play often with the customization of the shortcuts, so this way is sufficient for me.

danny0838 commented 8 years ago

Please check about:config and see whether dom.event.contextmenu.enabled is set to false. This will block any attempt to block the context menu from showing up so a right click always shows the context menu.

dom.event.contextmenu.enabled == true If I have well understood, it is the right value. Isn't it?

I'm not sure whether Control+Click is also affected by this setting. You can also test it for Control+Click issues.

Could you be more explicit?

It was suspected that right-click or control-click (as equivalent to right-click) for the isolate action of DOM Erasor has context menu popup is because your browser has dom.event.contextmenu.enabled = false. Since it's not the case by your report, we'd have to find the true cause in another way.

extensions.scrapbook.key.domEraser.narrower3 was set to Hyphen_Minus. I have deleted the _, setting it to HyphenMinus. Now it works again (as it did in 1.13.0b7).

...

Actually the key fires a search only if it is not defined as a hot-key, so it should not be a problem. As said above, - was not defined because the string Hyphen_Minus was not recognized as -.

You are right. This is the actual cause. It's a mistake we made during the coding job.

  1. Whether the scrollbar works in the options panel if the content overflows the dialog window.

Sorry, nothing have changed.

Could you check whether resizing the dialog window works? And whether mouse scroll has an effect?

  • Resizing works.
  • Mouse scroll works only when the scroll bars show up (which is not an unexpected behavior LOL).

That bad. It seems that Firefox has some special handling for Macs. We'd need further survay to fix the issue...

danny0838 commented 8 years ago

We close this issue since the support of command key of Mac (and also Mac style accesskey text) is already done. The issue of overflowing content in the dialog window will be investigated and discussed further in #122.

pascallothar commented 8 years ago

@danny0838 (Because the issue is close, I don't know if I can post here or if I have to post somewhere else. If needed, I can delete it and paste it somewhere else.)

I'm not sure whether Control+Click is also affected by this setting. You can also test it for Control+Click issues.

Could you be more explicit?

Ok, I understand now. I was already unneccessarily "translating" the Ctrl+Click in Cmd+Click :-D .

In DOM Eraser mode, when I use Ctrl+Click, it works exactly the same as RightClick, i.e. it will isolate AND make the contextual menu popping up.

It isn't the expected behavior, but, as I said before, it is not a big issue.


The newly implemented "Menu" == Alt+C does nothing (i.e. the first shortcut defined in the "Keys" tab). Which "Menu" is it?

Actually, in "HTML Editor" mode, it writes only ©, which is the default behavior if there is no shortcut defined.

Perhaps is it the implementation of a question I asked?:

Would it be difficult to implement some Help pop-up in Scrapbook X HTML Editor mode (I would say with shortcut Cmd+?) like the one in Scrapbook X DOM Eraser mode?

danny0838 commented 8 years ago

@pascallothar That's fine. Discussion about hotkeys on Mac can still go here, as long as the point is not more likely about the overflowing content issue.

The menu accesskey refers to the accesskey of the main menu, just like the "F" for file, "E" for edit, and so on. On Windows the default modifier for accesskeys is Alt (Some documentation says it's Alt+Shift. But by my test only Alt works). On Mac it seems to be Control+Option or Control.

Anyway, it seems that we should not simply write "Alt" here anymore. We'd think about another way to present it.

pascallothar commented 8 years ago

@danny0838 , I have to correct or precise my present comment, to not give you an information that could mislead you. Here are the links that I have found:

So, it seems that definitions of words have importance, beyond their intuitive meaning. And, of course, as usual, different sources have different definitions :-(

And it seems that on your documentation research, you have mixed two somewhat different stuff.



You learn me something. I have googled to find more.

The menu accesskey refers to the accesskey of the main menu, just like the "F" for file, "E" for edit, and so on. On Windows the default modifier for accesskeys is Alt

In the first link above, we can see that Microsoft Windows gives it the name "Mnemonic" (and not "accesskey") where others talk about "Hotkey". And that, indeed, on Windows, this letter has to be «pressed together with the Alt key».

For Mac, I have found among other stuff [http://superuser.com/questions/303525/what-is-the-shortcut-to-access-the-menubar-in-mac-os-x].

Before talking further, here is some clarification about the Function modifier key on Mac (fn). Some settings (like brightness of the screen, sound level, multimedia, ... ) use the function keys (F1, F2, ... ). By default, you will, for example, access directly (without modifier) to "increase brightness" by hitting the key above the key 2 (labelled with a big sun icon, and underneath it, in small letters, "F2"). To create the event F2, you will need to hit this same key with the modifier key fn down (fn+F2). But, in your system preferences, you can choose to invert this behavior, i.e. you will hit F2to create the event F2 and fn+F2 to increase the brightness of the screen. But, if I remember well, isn't it the same on Windows and Linux?

I have just tested it and, indeed, to access the menu bar (the Apple icon on the left of the menu bar to be precise), you need to create the F2 event with Ctrl down, i.e. to hit Ctrl+fn+F2by default or Ctrl+F2 if you made changes in your system preferences. And after that, you can navigate to the "Scrapbook X" sub-menu with the arrow keys and Return.

But anyway, it seems that on Mac, the way to go through the menu isn't the same as on Windows and that it is not possible, if I have well understood, to implement a shortcut for the direct access to the Scrapbook X entry in the menu bar. But is it really necessary, since no other entry of the menu bar is accessed this way on Mac?


On Windows the default modifier for accesskeys is Alt (Some documentation says it's Alt+Shift. But by my test only Alt works). On Mac it seems to be Control+Option or Control.

In [https://en.wikipedia.org/wiki/Access_key], we can see that what is defined by "accesskey" is something different. "Accesskeys" are implemented in web pages themselves and have their behavior totally variable from a certain web page to an other one. And, because it has been deprecated, it is seldom used in web pages.

Looking in the code of Scrapbook X, even if I don't understand a lot, I can see that it uses code having similarities with html (javascript, CSS, xul, xml, I don't know exactly). And that some functionalities are specified using the "accesskey attribute". ([https://en.wikipedia.org/wiki/Access_key#Specifying_access_keys]).

In [https://en.wikipedia.org/wiki/Access_key#Access_in_different_browsers], in the entry about Firefox, we can see that Windows on Firefox will not use Alt (as for "Mnemonics"), but Alt+Shift. And that, on Mac, it used to be Ctrl, but for the recent versions of Firefox, it is Ctrl + ⌥ Opt.

So, FYI, I made some test on my Mac with newest Firefox.

Anyway, it seems that we should not simply write "Alt" here anymore. We'd think about another way to present it.

I agree, since it's platform dependent and even Firefox version dependent.

pascallothar commented 8 years ago

@danny0838 , So, my second question is:

Would it be difficult to implement some Help pop-up in Scrapbook X HTML Editor mode (I would say with shortcut Cmd+?) like the one in Scrapbook X DOM Eraser mode?

pascallothar commented 8 years ago

@danny0838 , No answer: Does it mean that you didn't see my question OR that you had too much work and no time OR that it would be difficult to implement? :-)

Even to make some window (for example, saved as a file in the Scrapbook Directory to let the user fill it or edit it himself) pop up and let to the user the task to create the content of this pop-up?

danny0838 commented 8 years ago

@pascallothar What content you think should be written in a standalone help popup for the HTML editor?

pascallothar commented 8 years ago

In "DOM Eraser" mode, when you hit h, the help pop-up shows the usage of all the "hotkeys" (not even sure anymore if it is the right word, but anyway). And when you move the mouse or if you hit a second time h, the pop-up will disappear.

Here, in "HTML Editor" mode, one could choose a shortcut (Customizable would be better, of course; or something accessible with every keyboard layout and without conflicts with other not customizable shortcuts) that would make the usage window pop up with all the shortcuts used by "HTML Editor". And the window would disappear by moving the mouse. But also, to not use the mouse, by using the shortcut again (or and other one if not easy to implement).

What content? It depends of the implementation. It could be the same type as for "DOM Eraser". But, because the shortcuts are customizable, the pop up can not be "static" and NOT editable at the same time, because it needs to show the actual shortcuts and not the default ones.

If "static", it has to be customizable by the user, even if he has to use a not convivial way to do it (the user doesn't need to do that often, probably only once in its life) (Convivial would be a plus). This way could let more possibilities to the user. For example, for "Format with Template n", I would "Format" the string "Format with Template" or a part of the string or even a added word (depending perhaps of the type of formatting). So I could remember easily what template match to what shortcut. Adding an icon would be a plus, but is not a necessity.

If "dynamic" (i.e. the string matching the actual shortcut would be generated dynamically) and NOT editable by the user, one could use what is already shown by the contextual menu, but put together in a single window. An other possibility would be to create a shortcut that would make the contextual menu pop up immediately with the main sub-menu shown; but is it possible?

"Dynamic" AND editable would let the user add some "custom" tips and tricks, but more important to my eyes, let add some formatted example to the entry "Format with Template n".

But, as I said before, it depends of the type of implementation. Editable HTML or XHTML? Or something else? Because, I am not a developer, I have no clue of how to implement it exactly, only some approximative ideas.