1313061 - Context Menu shows all possible instead of related and required items

Status: RESOLVED WORKSFORME

(SeaMonkey :: General, defect)

Description

[hallobox]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 SeaMonkey/2.49a1
Build ID: 20161005004944

Steps to reproduce:

Installed latest trunk build (October 26th)
Open browser, right click on blank page or any web page



Actual results:

Context menu shows all possible entries including media controls etc. even on a blank page. You have to scroll through the menu to reach browser related links like "back"


Expected results:

Only relevant entries should be shown

Comment 1

[Rainer Bielefeld]

Attachment: Lots of unnecessary Context Menu Items.png

At German unofficial Blog user hbx found this mysterious behavior of context menus: <https://seamonkeyde.wordpress.com/2016/10/05/aurora-und-trunk-nightlies-sind-wieder-ueber-die-seamonkey-homepage-verfuegbar/#comment-361>.

Steps how to reproduce with official en-US SeaMonkey 2.49a1  (NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 Build 20161026000046  (Default Classic Theme) on German WIN7 64bit:

1. In Browser open arbitrary web page, for example 
   <http://www.seamonkey-project.org/>
2. Rightclick arbitrary hyperlink
   Expected: context menu with some few items
   Actual: context menu fills all window height and more

a) I am pretty sure that I already saw this problem some time ago, but 
   I did not find a bug report.

Comment 2

[Rainer Bielefeld]

b) Currently only observed with WIN7, others not tested.

Comment 3

[Rainer Bielefeld]

c) Also other context menus are affected, for example when you 
   rightclick into Email Composer Window.

Comment 4

[Rainer Bielefeld]

Also with linux due to Newsgroup "de.comm.software.mozilla.misc" -- "SM: Linux Bugs bestätigen - Bug 1313061"

Comment 5

[Rainer Bielefeld]

d) Thunderbird not affected due to Newsgroup "de.comm.software.mozilla.misc" -- "SM: Linux Bugs bestätigen - Bug 1313061"

Comment 6

[Rainer Bielefeld]

e) Together with all other problems which appeared 2 days ago (or so) 
   the estimated common root is a blocker.

Comment 8

[Tony Mechelynck [:tonymec]]

Regression range using L64 nightlies (bug 1313553 comment #0):

User agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49a1

Last known good:
20161025003001
http://hg.mozilla.org/comm-central/rev/2294e347fd430898dfb226cf61b1496cd031d475
http://hg.mozilla.org/mozilla-central/rev/c845bfd0accb

First known bad:
20161026003001
http://hg.mozilla.org/comm-central/rev/b1603f2d0e691644f1390761695ff2036b42443a
http://hg.mozilla.org/mozilla-central/rev/f9f3cc95d728

Happens also in Safe Mode.

Comment 9

[Tony Mechelynck [:tonymec]]

In addition, the menu is not fully functional. For instance, when right-clicking a link, "Open link in new tab" is present but does nothing. Opening the link in a new tab requires "Copy link location" (which works) followed by New tab (Ctrl+T), Paste (Ctrl+V), Go to URL bar contents (Enter).

Comment 10

[Frank-Rainer Grahl (:frg)]

Likely fallout from bug 1312143 too. Did go away with the hack patch in bug 1313288. I didn't have time to investigate this further but shouldn't be hard to fix. Either we keep the parts or remove them. Does it also occur in a fresh profile if cz and inspector are not installed in a build with bug 1313039 applied?

Comment 11

[Tony Mechelynck [:tonymec]]

(In reply to Frank-Rainer Grahl from comment #10)
> Likely fallout from bug 1312143 too. Did go away with the hack patch in bug
> 1313288. I didn't have time to investigate this further but shouldn't be
> hard to fix. Either we keep the parts or remove them. Does it also occur in
> a fresh profile if cz and inspector are not installed in a build with bug
> 1313039 applied?

Bug 1313039 was RESOLVED FIXED on the 26th. In the SeaMonkey L64 2016-10-27 nightly, the bug happens even in Safe Mode, which disables all extensions including cZ and DOMi (see comment #8).

Comment 12

[Tony Mechelynck [:tonymec]]

P.S. Comment #8 was before the 1313039 landing, but I did check that on the latest nightly (that of the 27th) the bug still happens in Safe Mode.

Comment 13

[Tony Mechelynck [:tonymec]]

P.P.S. Not nightly, but an hourly built from mozilla-central changeset a1ac8eae4234ff0280aab2ee5fe8175598d1ef57 which is after bug 1313039's mozilla-central changeset f8953e4e9a6417bfc0391ab214610d19e31b596d

Comment 14

[Tony Mechelynck [:tonymec]]

I meant comm-central :-/

Comment 15

[Frank-Rainer Grahl (:frg)]

I believe this will go away when bug 1313288 is fixed. Probably a duplicate.

Comment 16

[Tony Mechelynck [:tonymec]]

(In reply to Frank-Rainer Grahl from comment #15)
> I believe this will go away when bug 1313288 is fixed. Probably a duplicate.

Bug 1313288 was reported FIXED on the 26th, approximately at the same time as bug 1313039 (comment #10), and this bug still affects, e.g., builds made on the 27th, so it cannot be a DUPLICATE of either of them.

Comment 17

[Tony Mechelynck [:tonymec]]

(In reply to Tony Mechelynck [:tonymec] from comment #16)
> (In reply to Frank-Rainer Grahl from comment #15)
> > I believe this will go away when bug 1313288 is fixed. Probably a duplicate.
> 
> Bug 1313288 was reported FIXED on the 26th, approximately at the same time
> as bug 1313039 (comment #10), and this bug still affects, e.g., builds made
> on the 27th, so it cannot be a DUPLICATE of either of them.

Oops, wrong bug report checked. Discard this comment.

Comment 18

[Tony Mechelynck [:tonymec]]

(In reply to Frank-Rainer Grahl from comment #15)
> I believe this will go away when bug 1313288 is fixed. Probably a duplicate.

There is a comment (by you) in bug 1313288 saying it "might be unneeded" because it exhibits the same behaviour as bug 1313039. Now bug 1313039 was FIXED on the 26th and this bug still appears in later builds, so if 1313288 is eventually duped to 1313039 this bug cannot be a dupe of them.

This is how comment #16 ought to have been formulated. Too early after getting out of bed, I'll go make some coffee.

Comment 19

[Frank-Rainer Grahl (:frg)]

Anyway. Please try the latest tinderbox build or the next nightly. This was imho cause by a missing spellcheckerui and caused the problem in nsContextMenu.js.

Comment 20

[Tony Mechelynck [:tonymec]]

UA:"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49a1" 
ID:20161106003001 en-US 
c-c:e0d8cfec4210f377ecb4de5d0191d5deb0a49cdc 
m-c:c44c01dfd264370c1558b747525d220a9a89b51c

This problem has now disappeared: this L64 nightly has context menus of "reasonable" length, where "Open link in new tab" works, "View image" and "Save image as" are present and functional, etc.

Rainer: Has the bug also disappeared for you on the latest Windows builds? If no one experiences it anymore it can be set to VERIFIED.