-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
make need of execCommand to hide table controls go away on FF #171
Comments
@masayuki-nakano @ayg Any reason not to specify this as incorrect? |
Sorry. I didn't realize your request. (If you wait some reply from me in some other issues, let me know.) Sounds like this is very important incompatible issue. I filed a bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1449564 and perhaps, it'll be fixed in 61 (unfortunately, next ESR is 60, though). |
When I wrote patches of Firefox, I realized that Gecko has another built-in feature. That's a grabber to move absolute positioned elements with dragging it. I'd like to disable it by default too and making web apps possible to enable it by new command "enableAbsolutePositionEditor" at least for now for backward compatibility. Then, we can collect actual usage of those features with telemetry and if telemetry tells us nobody uses those Gecko built-in editing features, we can completely removed them from Firefox safely. @johanneswilm Do you have some comments about this? |
@masayuki-nakano I agree. I think it's unproblematic as it will be a Firefox-only command and so it will likely only be used by those who make use of that feature currently. |
Updating current status: We started to collect usage of each UI from Beta users. As far as checking same data collected from Nightly users, we can not remove the Gecko specific UI completely, but perhaps, it's okay to hide the UI by default. |
Hiding it by default would be all JS devs are asking for, as this would put Firefox in line with other browsers so that they don't need to include special Firefox-code for this. |
Will the commands to enable the UI again be standardized and implemented by other browsers? Or is the plan that we eventually remove the UI for this from Firefox completely? |
There have been no requests that I am aware of by any of the JS editor projects to add these controls in other browsers. It's all just about making them go away in Firefox without having to add extra code. Adding controls in JS when they are needed does not seem to be an issue for the editors. That being said, if there is an interest of other browsers to add such controls optionally, I would not be opposed to working on standardizing this if that makes Firefox remove them quicker. |
I think the work to disable the UI by default is ongoing and making progress, but I'm wondering about the long term API surface here. Ideally all browsers expose the same set of controls. So either Fx removes these at some point or other browsers also adopt them. |
I doubt the controls will be used by any new JS projects, whether standardized or not. The only reason it cannot be removed entirely from Firefox is that the Firefox team found out that the UI is still being used in some places. Maybe special in-house corporate apps that only run on Firefox, etc. . |
Yes, I'm working on disabling the UI by default on Firefox, for compatibility with the other browsers. And as @johanneswilm said, we've found a few users are actually using the Gecko specific UIs: I don't think that such complicated UI should be standardized since it's difficult to keep compatibility with all browsers and all platforms. Additionally, anyway not a few web developers want to customize only a part of the UIs. So, if web apps require such UIs, web apps should implement them by themselves. |
And currently, we will disable the UIs by default starting from 64 (2018-12-11) if we won't meet any problems. |
…ild r=m_kato Currently, we have some Gecko specific editing UI: - Resizers to resize <img>s, <table>s, absolutely positioned elements. - Inline-table-editing UI to add/remove rows/columns. - Grabber to move absolutely positioned element. They are now disabled by default in Nightly and early-Beta. Starting from 64, this patch makes them disabled by default even on release channel. Note that the other browsers do not have those UIs and web apps can enable them with document.execCommand() on Gecko anyway. Those UI usage is enough low according to the telemetry, but a few users use them aggressively (see bug 1452538 comment 19). This is a request from W3C Editing API WG: w3c/editing#171 Differential Revision: https://phabricator.services.mozilla.com/D6112 --HG-- extra : moz-landing-system : lando
…ild r=m_kato Currently, we have some Gecko specific editing UI: - Resizers to resize <img>s, <table>s, absolutely positioned elements. - Inline-table-editing UI to add/remove rows/columns. - Grabber to move absolutely positioned element. They are now disabled by default in Nightly and early-Beta. Starting from 64, this patch makes them disabled by default even on release channel. Note that the other browsers do not have those UIs and web apps can enable them with document.execCommand() on Gecko anyway. Those UI usage is enough low according to the telemetry, but a few users use them aggressively (see bug 1452538 comment 19). This is a request from W3C Editing API WG: w3c/editing#171 Differential Revision: https://phabricator.services.mozilla.com/D6112 UltraBlame original commit: aeedb53775769e6ccc5bd361491529a71009b129
…ild r=m_kato Currently, we have some Gecko specific editing UI: - Resizers to resize <img>s, <table>s, absolutely positioned elements. - Inline-table-editing UI to add/remove rows/columns. - Grabber to move absolutely positioned element. They are now disabled by default in Nightly and early-Beta. Starting from 64, this patch makes them disabled by default even on release channel. Note that the other browsers do not have those UIs and web apps can enable them with document.execCommand() on Gecko anyway. Those UI usage is enough low according to the telemetry, but a few users use them aggressively (see bug 1452538 comment 19). This is a request from W3C Editing API WG: w3c/editing#171 Differential Revision: https://phabricator.services.mozilla.com/D6112 UltraBlame original commit: aeedb53775769e6ccc5bd361491529a71009b129
…ild r=m_kato Currently, we have some Gecko specific editing UI: - Resizers to resize <img>s, <table>s, absolutely positioned elements. - Inline-table-editing UI to add/remove rows/columns. - Grabber to move absolutely positioned element. They are now disabled by default in Nightly and early-Beta. Starting from 64, this patch makes them disabled by default even on release channel. Note that the other browsers do not have those UIs and web apps can enable them with document.execCommand() on Gecko anyway. Those UI usage is enough low according to the telemetry, but a few users use them aggressively (see bug 1452538 comment 19). This is a request from W3C Editing API WG: w3c/editing#171 Differential Revision: https://phabricator.services.mozilla.com/D6112 UltraBlame original commit: aeedb53775769e6ccc5bd361491529a71009b129
On Firefox, one needs to execute these two execCommands globally to make table controls go away. Table controls are generally implemented in JavaScript anyway, and this makes the Firefox implementation work differently than any other browser.
Can we make it clear that there should be no table controls to begin with, as is the case on all browsers except Firefox? All known editors execute these two commands after loading a page to make the table commands go away. Apparently these are global settings that work for all tables on a page.
See for example:
https://github.com/ckeditor/ckeditor-dev/blob/fc149eeb4b92ba9ea64c6becee9e0ddff906097f/plugins/wysiwygarea/plugin.js#L554-L558
The text was updated successfully, but these errors were encountered: