1389351 - After upgrading to version 55, Firefox shows a context menu after a significant delay.

Status: RESOLVED WORKSFORME

(Firefox :: Menus, defect, P4)

Description

[rshimazu]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170809080026

Steps to reproduce:

Try to show a context menu.



Actual results:

A context menu shows up after 2 to 8 seconds.


Expected results:

A context menu should show up after no delay.

Comment 1

[rshimazu]

I am using Windows 7.
If I run Firefox safe mode, it does not show any problem.
But manually disabling all addons does not solve the problem.
New profile does not solve the problem, either.

Comment 2

[rshimazu]

Disabling hardware acceleration has solved the problem!

But anyway before upgrading to Firefox 55, namely, up to Firefox 54 there had been no problem in the same machine.

Comment 3

[Jim Mathies [:jimm]]

Can you provide STR / details about the context menu you were testing with?

Comment 4

[rshimazu]

I am sorry but I do not know the meaning of STR.

Just try to use the right click menu on any web page, or try to use the right click menu on the address bar in order to paste a certain url. Or try to use the right click on the search box right next to the address bar in order to paste a search keyword.
Alternatively, try to use the menu bar (ex. Tools -> Option) then the menu shows up after a significant delay even though this may not be a kind of context menu.

Is this explanation in accord with what you have asked?

Comment 5

[Panos Astithas (he/him) [:past] (please ni?)]

Could you post your about:support contents here please?

Comment 6

[Panos Astithas (he/him) [:past] (please ni?)]

Ciprian, could you reproduce this?

Comment 7

[Ciprian Muresan [:cmuresan], Formerly of Ecosystem QA - please needinfo @mcoman for things regarding the team]

User Agent 	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID 	20170822171841

I am unable to reproduce the issue on the latest Nightly using a very old profile or on Firefox release 55.0.2 using a new profile on Windows 10. Context menus appear under a second for me. 

I've also tried the same on a different machine using Windows 7, but no luck.

Comment 8

[rshimazu]

Attachment: support.txt -- after disabling Hardware acceleration

This is my about: support after disabling hardware acceleration.

Comment 9

[rshimazu]

Attachment: support_problem.txt -- before disabling hardware acceleration

Most of the texts are Japanese.
Do you understand Japanese?
This attachment is my about:support before disabling hardware acceleration, so I have the contextmenu problem in this case.

Comment 10

[rshimazu]

Comparing two "about:support" files:'before' and 'after',

Before enabling hardware acceleration, the most important part may be the following (This is an excerpt from 'before'):

AzureCanvasAccelerated: 0
AzureCanvasBackend (UI Process): skia
AzureContentBackend (UI Process): skia
AzureFallbackCanvasBackend (UI Process): cairo
GPUProcessPid: 6732
failures: CP+[GFX1]: Potential driver version mismatch ignored due to missing DLLs igd10umd64 v= and igd10iumd64 v=
決定ログ
D3D11_COMPOSITING:
failed by runtime: Failed to acquire a D3D11 device
DIRECT2D:
ブロックリストに掲載。失敗コード BLOCKLIST_FEATURE_FAILURE_DL_BLACKLIST_g984
D3D11_HW_ANGLE:
disabled by env: D3D11 compositing is disabled
WEBRENDER:
opt-in by default: WebRender is an opt-in feature
unavailable by runtime: Build doesn't include WebRender

Comment 11

[Mike Taylor [:miketaylr]]

Given Comment #2, any ideas here Milan?

Comment 12

[Milan Sreckovic [:milan] (needinfo for best results)]

What happens if you leave acceleration enabled (as is the default), but set layers.gpu-process.allow-software to false?  Is the problem gone, or is it still there (in which case, can we have the about:support graphics for that scenario as well?)

Comment 13

[rshimazu]

Attachment: graphics.txt

This is about:suppport graphics section , which I have made after setting layers.gpu-process.allow-software to false.

The problem is still there when I do not disable hardware acceleration.

Bye the way, in my about:config, layers.gpu-process.allow-software does not exist in my Firefox and therefore I created it.

Comment 14

[Milan Sreckovic [:milan] (needinfo for best results)]

I was trying to sort out why something would show up as a problem with blocked acceleration vs. pref'd off acceleration.  One difference is the compositor process, but I'm not sure why that preference is not showing up for you.  It certainly didn't seem to make a difference, the compositor process still showed up.

We do have places accessing this preference in JS, but most of it is tests or the actual performance UI [1].


[1] https://dxr.mozilla.org/mozilla-central/search?q=layers.acceleration.disabled&=mozilla-central

Comment 15

[Jared Wein [:jaws] (please needinfo? me)]

Given that this hasn't been fixed in three releases (55, 56, 57) and that we have had trouble reproducing this I'm going to mark this as P4 (would have been P5 but the jank reported in comment #0 is really bad).

rshimazu, can you still reproduce this with the latest Firefox Nightly build (http://nightly.mozilla.org/). If you can still reproduce this, can you get a profile from the Gecko Profiler (https://perf-html.io/)? 

The profile from the Gecko Profiler will allow us to see exactly what lines of code are slowing down Firefox on your machine.

Comment 16

[rshimazu]

Please close the report.
On Firefox 57 (64bit/Windows 7) I do not see the problem any more.

Comment 17

[Marco Bonardo [:mak]]

Thanks for reporting back.