Cut and Copy menuitem are enabled when Nightly starts up

RESOLVED INVALID

Status

()

Core
DOM
RESOLVED INVALID
2 years ago
10 months ago

People

(Reporter: u520171, Unassigned)

Tracking

({regression, ux-mode-error})

41 Branch
regression, ux-mode-error
Points:
---

Firefox Tracking Flags

(firefox41- affected, firefox42- affected)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

2 years ago
User Agent: Mozilla/5.0 (Windows NT 6.3; rv:41.0) Gecko/20100101 Firefox/41.0
Build ID: 20150627030211

Steps to reproduce:

1) Confirm Cut and Copy menuitem are disabled or enabled after start up Firefox, Firefox Beta and Firefox Developer Edition. (Normally disabled)
2) Start up Nightly, then confirm Cut and Copy menuitem are disabled or enabled.

Environments:
Windows 8.1 (32 bit) / OS X 10.10 Yosemite
- Firefox Nightly 41.0a1 (2015-06-26)

The following build works well
- Firefox Developer Edition 40.0a2 (2015-06-26)
- Firefox 39.0 (2015-06-24)
- Firefox 38.0.5 (2015-05-25)


Actual results:

Cut and Copy menuitem are enabled on Nightly.


Expected results:

Cut and Copy menuitem are disabled.
(Reporter)

Updated

2 years ago
Component: Untriaged → General

Comment 1

2 years ago
This problem also has occurred on the following builds.

- Nightly 42.0a1 (20150629134017)
- Firefox Developer Edition 41.0b2 (20150629134017)

Comment 2

2 years ago
Created attachment 8631026 [details]
menuitem-enabled-disabled.png

Please refer to the attached image.

Comment 3

2 years ago
Created attachment 8631044 [details]
menuitem-enabled-disabled-noclip.png

Please refer to the attachment image
(No clipboard)
Attachment #8631026 - Attachment is obsolete: true
Would be helpful to know exactly which Nightly build broke this.

One can do this by manually downloading and testing builds from https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/, or using mozregression -- a tool to help automate this: http://mozilla.github.io/mozregression/
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regressionwindow-wanted

Comment 5

2 years ago
(In reply to Justin Dolske [:Dolske] from comment #4)
> Would be helpful to know exactly which Nightly build broke this.
> 
> One can do this by manually downloading and testing builds from
> https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/, or using
> mozregression -- a tool to help automate this:
> http://mozilla.github.io/mozregression/

I confirmed that this problem occur on Nightly build 2015-05-27 and later.

app_name: firefox
build_date: 2015-05-27
build_path: k:\tmpc_9x4u\2015-05-27--mozilla-central--firefox-41.0a1.en-US.win32.zip
build_txt_url: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2015/05/2015-05-27-13-54-46-mozilla-central/firefox-41.0a1.en-US.win32.txt
build_type: nightly
build_url: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2015/05/2015-05-27-13-54-46-mozilla-central/firefox-41.0a1.en-US.win32.zip
changeset: ff2e07228041
pushlog_url: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c6bbf8f1b02b&tochange=ff2e07228041
repo: mozilla-central
repository: https://hg.mozilla.org/mozilla-central

Comment 6

2 years ago
[Tracking Requested - why for this release]:

[Tracking Requested - why for this release]:

Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=dc683817edec&tochange=1921222e708e

Suspect:
 0431f570160d	Michael Layzell — Bug 1162952 - Return true from document.queryCommandEnabled('cut'/'copy') when in privileged or user-initiated code. r=ehsan
Blocks: 1162952
status-firefox41: --- → affected
status-firefox42: --- → affected
tracking-firefox41: --- → ?
tracking-firefox42: --- → ?
Component: General → DOM
Flags: needinfo?(michael)
Keywords: regressionwindow-wanted → regression, ux-mode-error
Product: Firefox → Core
I believe that this is intended behavior. On firefox startup under the default configuration, your focus is in the about:home textbox. about:home is an HTML page, and in HTML pages we now need to always enable the cut and copy commands. Thus, they are enabled on startup.

The cut and copy commands should always be enabled in HTML pages, as it is now possible to intercept and handle the cut and copy events in web pages. As these events should be possible to fire whether or not there is a selection (and it is possible to copy values to the clipboard whether or not there is a selection), we must keep these commands enabled in case they are intercepted and handled by custom content javascript code.

I'm ni-ing ehsan to confirm that I'm correct on this.
Flags: needinfo?(michael) → needinfo?(ehsan)

Comment 8

2 years ago
(In reply to Michael Layzell [:mystor] from comment #7)
> I believe that this is intended behavior. On firefox startup under the
> default configuration, your focus is in the about:home textbox. about:home
> is an HTML page, and in HTML pages we now need to always enable the cut and
> copy commands. Thus, they are enabled on startup.
> 
> The cut and copy commands should always be enabled in HTML pages, as it is
> now possible to intercept and handle the cut and copy events in web pages.
> As these events should be possible to fire whether or not there is a
> selection (and it is possible to copy values to the clipboard whether or not
> there is a selection), we must keep these commands enabled in case they are
> intercepted and handled by custom content javascript code.
> 
> I'm ni-ing ehsan to confirm that I'm correct on this.

I have confirmed the cut and copy status (NOT all view) on the latest Nightly.
If you are correct, should fix [disabled] items?

[Enabled]
about:accounts
about:app-manager
about:buildconfig
about:cache
about:crashes
about:credits
about:healthreport
about:home
about:license
about:logo
about:memory
about:mozilla
about:networking
about:performance
about:plugins
about:privatebrowsing
about:rights
about:robots
about:serviceworkers
about:sessionrestore
about:support
about:sync-log
about:telemetry
about:webrtc
about:welcomeback
Developer Tools: searchbar in Rules, Computed
Developer Tools: code panes


[Disabled]
urlbar in nav-bar
searchbar in nav-bar
searchbar in Bookmarks sidebar
about:addons
about:config
about:newtab
about:preferences#general Home Page
about:preferences#search Keyword
about:preferences#content Exceptions -> Address of website
about:preferences#applications Searchbar
about:preferences#privacy Exceptions -> Address of website
about:preferences#privacy Show Cookies -> Searchbar
about:preferences#security Exceptions -> Address of website
about:preferences#advanced Network -> Connection Settings
about:permissions
about:sync-tabs
Developer Tools: searchbar in Inspector
Developer Tools: Web Console
Developer Tools: searchbar in Debugger
Developer Tools: searchbar in Network Monitor
Bookmark Library
History Library

Comment 9

2 years ago
This is intended.  Neil Deakin asked us to disable this behavior for XUL documents which is why these entries are disabled in the pages you listed above.  There is no work remaining to be done here.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Flags: needinfo?(ehsan)
Resolution: --- → INVALID
Based on comment 9, I do not feel the need to track this for FF41 and FF42.
tracking-firefox41: ? → -
tracking-firefox42: ? → -

Comment 11

2 years ago
(In reply to Ehsan Akhgari (not reviewing patches, not reading bugmail, needinfo? me!) from comment #9)
> This is intended.  Neil Deakin asked us to disable this behavior for XUL
> documents which is why these entries are disabled in the pages you listed
> above.  There is no work remaining to be done here.

Why? Users don't know HTML or xul documents. Especially about:home and about:newtab. It's just strange behavior for users. That all.

Comment 12

2 years ago
(In reply to magicp from comment #11)
> (In reply to Ehsan Akhgari (not reviewing patches, not reading bugmail,
> needinfo? me!) from comment #9)
> > This is intended.  Neil Deakin asked us to disable this behavior for XUL
> > documents which is why these entries are disabled in the pages you listed
> > above.  There is no work remaining to be done here.
> 
> Why? Users don't know HTML or xul documents. Especially about:home and
> about:newtab. It's just strange behavior for users. That all.

Asking Neil.  I have no strong opinions on this.
Flags: needinfo?(enndeakin)

Comment 13

2 years ago
The issue is that HTML doesn't provide a means of indicating to the UI that the clipboard commands should be enabled. Rather than provide this, bug 1159490 just made them enabled all the time. Chrome does something similar. XUL does provide such a means so it should be used to ensure the UI is correct (as Chrome also does for the browser UI) We could do something similar though and use the right UI for about pages or chrome: files or something.

Note that in my opinion, the html behaviour is broken and bug 1159490 is invalid.
Flags: needinfo?(enndeakin)

Updated

2 years ago
Duplicate of this bug: 1271897

Updated

a year ago
Duplicate of this bug: 1303033

Updated

10 months ago
See Also: → bug 1328029
You need to log in before you can comment on or make changes to this bug.