725250 - Page context menus AND custom toolbars are messed up (caused by some extension accessing the browser window's document before the load or DOMContentLoaded event which messes up the overlays).

Status: NEW

(SeaMonkey :: Sidebar, defect)

Description

[Andrey ``Bass'' Shcheglov]

Attachment: Context menu for a hyperlink: no "Open Link in New Tab" menu item

There're 2 symptoms which I believe to be the same problem:


1. Page context menus (which appear on right-click) are often missing the required menu items (like "Copy" for the selected text or "Open Link in New Tab" for a hyperlink), or, alternatively, contain *all possible* menu items, even inappropriate for the current selection (see the screenshots).

2. Custom toolbars are sometimes displayed twice in the same window (will attach a screenshot as soon as I reproduce the problem again). Basically, once you customize the default layout a little bit, you start experiencing layout problems.


I have all plugins and extensions temporarily disabled, still the symptoms don't go away. Can't reproduce the problem in safe mode, because it's impossible to change the UI layout in safe mode.

Can't reproduce the problem with any alternative SeaMonkey profile, as I haven't found a guide explaining how to migrate a SM 2.x profile into another 2.x profile and which files can be safely left aside.


The problem isn't new to SM 2.7 -- seen the same since SM 2.1, but now the problems are so often that I consider temporarily switching to another browser/email client until the issue is fixed.


Here's the buildconfig:

Source

Built from http://hg.mozilla.org/releases/mozilla-release/rev/3851ce93e81f

Build platform

target

x86_64-apple-darwin10

Build tools

Compiler 	Version 	Compiler flags

gcc-4.2 -arch x86_64 	
gcc version 4.2.1 (Apple Inc. build 5646) (dot 1) 	
-Wall -W -Wno-unused -Wpointer-arith -Wdeclaration-after-statement -Wcast-align -W -gdwarf-2 -isysroot /Developer/SDKs/MacOSX10.6.sdk -fno-strict-aliasing -fno-common -pthread -DNO_X11 -DNDEBUG -DTRIMMED -gdwarf-2 -O3 -fomit-frame-pointer

g++-4.2 -arch x86_64 	
gcc version 4.2.1 (Apple Inc. build 5646) (dot 1) 	
-fno-rtti -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type -gdwarf-2 -isysroot /Developer/SDKs/MacOSX10.6.sdk -fno-exceptions -fno-strict-aliasing -fno-common -fshort-wchar -pthread -DNO_X11 -DNDEBUG -DTRIMMED -gdwarf-2 -O3 -fomit-frame-pointer

Configure arguments

--target=x86_64-apple-darwin10 --with-macos-sdk=/Developer/SDKs/MacOSX10.6.sdk --enable-application=suite --enable-update-channel=release --enable-update-packaging --enable-tests --enable-debug-symbols=-gdwarf-2 --target=x86_64-apple-darwin10 --with-macos-sdk=/Developer/SDKs/MacOSX10.6.sdk --enable-application=suite --enable-update-channel=release --enable-update-packaging --enable-tests --enable-debug-symbols=-gdwarf-2 --enable-application=../suite --disable-official-branding --with-branding=../suite/branding/nightly --cache-file=.././config.cache --srcdir=/builds/slave/rel-comm-rel-osx64-bld/build/mozilla

Comment 1

[Andrey ``Bass'' Shcheglov]

Attachment: Context menu for a selected text: contains all possible menu items

Comment 2

[Andrey ``Bass'' Shcheglov]

Attachment: Context menu for a selected text: no "Copy" menu item

The problem has also been reproduced after an upgrade to SM 2.7 on Windows (see the screenshot).

The exact build identifiers are:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20120129 SeaMonkey/2.7
Mozilla/5.0 (Windows NT 5.1; rv:10.0) Gecko/20120129 Firefox/10.0 SeaMonkey/2.7

Comment 3

[therube]

DUP of Bug 671192 - Command "Paste without Formatting" in message window is missing

Comment 5

[Ian Neal]

Bug 671192 is to do with a specific bug with event handlers having the same original prototype node which has a workaround that landed in bug 674246
What would be useful for this bug, to accompany each screen shot, is any relevant messages from the error console.

Comment 6

[Ian Neal]

(In reply to Andrew ``Bass'' Shcheglov from comment #0)

> Can't reproduce the problem with any alternative SeaMonkey profile, as I
> haven't found a guide explaining how to migrate a SM 2.x profile into
> another 2.x profile and which files can be safely left aside.

Both mozillazine and http://seamonkey.ilias.ca/profilefaq/ have information about copying a profile.

Comment 7

[Andrey ``Bass'' Shcheglov]

(In reply to Ian Neal from comment #5)
> Bug 671192 is to do with a specific bug with event handlers having the same
> original prototype node which has a workaround that landed in bug 674246
> What would be useful for this bug, to accompany each screen shot, is any
> relevant messages from the error console.

Hi Ian.

Once I select a text and right-click it for the popup menu
(menu appearance is consistent with <https://bugzilla.mozilla.org/attachment.cgi?id=595378>),
I can see the following 4 messages in the JavaScript console:


Error: sidebarObj.panels is undefined
Source File: chrome://navigator/content/navigator.js
Line: 1216

Error: cm is null
Source File: chrome://flashblock/content/flashblock.js
Line: 369

Error: gContextMenu is null
Source File: chrome://navigator/content/mailNavigatorOverlay.js
Line: 179

Error: gContextMenu is null
Source File: chrome://editor/content/editorApplicationOverlay.js
Line: 42


I believe the second one can be ignored -- it is only relevant to Flashblock extension.

Comment 8

[Andrey ``Bass'' Shcheglov]

I've closed the sidebar,
disabled Flashblock and restarted SM.

Now the popup menu appearance is consistent with attachment 595360 [details],
but console messages are the same:


Error: sidebarObj.panels is undefined
Source File: chrome://navigator/content/navigator.js
Line: 1216

Error: gContextMenu is null
Source File: chrome://navigator/content/mailNavigatorOverlay.js
Line: 179

Error: gContextMenu is null
Source File: chrome://editor/content/editorApplicationOverlay.js
Line: 42


Please let me know whether I can help with any further investigation.

Comment 9

[Philip Chee]

*Normally* these error messages are caused by a badly behaving extension, but you say you've disabled all extensions and plugins.

> Can't reproduce the problem with any alternative SeaMonkey profile, as I haven't found
> a guide explaining how to migrate a SM 2.x profile into another 2.x profile and which
> files can be safely left aside.

I would go the other way. Create a new fresh profile, and then copy files one by one from the problematic profile until the problem resurfaces.

The files you can start with are probably:

localstore.rdf followed by
prefs.js
places.sqlite
bookmarks.html
panels.rdf




plugin

Comment 10

[Phoenix]

Does advice in Comment 9 helps you?

Comment 11

[Andrey ``Bass'' Shcheglov]

Hi.

No it doesn't actually -- I keep experiencing the problem even with clean profiles (no extensions) on both Windows and Mac OS X.

I'll investigate further and get back to you before 2012-05-01.

Comment 12

[Andrey ``Bass'' Shcheglov]

Additionally,
the same behaviour is often seen with IceApe (SeaMonkey fork by the Debian project).

Comment 13

[Andrey ``Bass'' Shcheglov]

Hi.

It looks like the problem isn't easy to reproduce.


Installing Adblock Plus <http://adblockplus.mozdev.org> over a clean profile made the problem immediately manifest itself (context menus with all possible menu items available).

Additionally, uninstalling Adblock Plus wasn't helpful: there still were remains of it in localstore.rdf, prefs.js and some sqlite databases, and context menus were still messed up.


For verification purposes, I tried to re-trace the above steps.

Installing Adblock Plus the second time over a clean profile, however, didn't make the problem appear.


Since installation of a certain extension does not always trigger the problem, we can't claim there's a problem in the extension X rather than SeaMonkey.


So this is definitely not a WFM -- just someone is more lucky than me.

Comment 14

[Andrey ``Bass'' Shcheglov]

While removing localstore.rdf (replaced it with localstore-safe.rdf) and customising the toolbars from scratch allowed to reduce its size from 88k down to 15k,
the problem with toolbars and context menus still persists.

And, as I wrote earlier, there's no problem at all with a similar profile with the same UI layout and the same extensions installed.

Comment 15

[Andrey ``Bass'' Shcheglov]

1. The issue with context menus is gone
(despite I'm not sure it's gone forever)
after copying localstore.rdf from a clean profile.

2. The issue with toolbars went away once I've manually updated all the add-ons.

While SeaMonkey still proves itself as an unstable software,
at least I now know the steps which may fix UI problems.

Comment 16

[Phoenix]

Okay, so installing Adblock is triggering unwanted behavior. Can you try to reproduce problem on latest nightly from http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-comm-central-trunk/
If it still reproducible, can you provide archive with working profile before installing add-on and broken profile after install.

Comment 17

[Wladimir Palant]

The problem as you describe it is usually caused by some extension accessing the browser window's document too early (before the load or DOMContentLoaded event) which messes up the overlays. Adblock Plus merely makes it visible because it uses a complicated UI solution (an overlay applying to an overlay).

Comment 18

[Philip Chee]

And of course SeaMonkey Navigator code uses overlays on overlays extensively.

Comment 19

[Phoenix]

Andrew?

Comment 20

[Andrey ``Bass'' Shcheglov]

After a number of SeaMonkey crashes,
the problem is showing itself again.

Right-clicking the same page or link or selected text fragment twice in a row
bay bring up two context menus that are different (only one of those being correct).

No SeaMonkey or add-on updates were installed since my last message.

It looks like one should backup his/her localstore.rdf and stuff on a daily basis.

Will try to reproduce on a nightly build as you suggested.

Comment 21

[Andrey ``Bass'' Shcheglov]

I've uploaded the complete profile directory (along with extensions) which can be used to reproduce the problem with context menus (available at <http://devio.us/~bass/4oxb9mjn.default.tar.bz2>).

Please let me know whether you need any further information from my side.

Comment 22

[Andrey ``Bass'' Shcheglov]

The problem still exists for this particular profile
when testing it with the latest nightly build:

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/15.0 Firefox/15.0a1 SeaMonkey/2.12a1
Build identifier: 20120527003003

Comment 23

[Andrey ``Bass'' Shcheglov]

Additionally, I have a profile w/o any extensions at all (except the standard ChatZilla, DOM Inspector and JavaScript Debugger) which has the same problem with context menus.

I'll upload it tomorrow.

Comment 24

[Andrey ``Bass'' Shcheglov]

Also, it looks like Firefox 8.0 ... 10.0 builds, even with the same set of extensions,
don't suffer from such a problem.

At least, I never saw anything similar using Firefox.

Comment 25

[Andrey ``Bass'' Shcheglov]

Attachment: uw09l9nx.Clean.rar (Profile directory from SeaMonkey 2.8/Windows)

As I promised earlier,
I'm uploading the profile directory created by the Windows build
(Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Firefox/11.0 SeaMonkey/2.8).

All extensions and private data have been removed (I hope =).

I'm also attaching a screenshot of SeaMonkey with this very profile active.

Comment 26

[Andrey ``Bass'' Shcheglov]

Attachment: uw09l9nx.Clean.png

Comment 27

[Wladimir Palant]

Attachment: Minimal localstore.rdf to reproduce the issue

I was able to reproduce the issue in SeaMonkey 2.9.1 with the profile attached - the context menu stays uninitialized (all entries shown at the same time), error messages like "gContextMenu is undefined" in Error Console. It seems unrelated to any extensions, the reduced localstore.rdf contains only two persisted attributes for the sidebar-splitter element. Putting this localstore.rdf file into a brand-new SeaMonkey profile makes the issue appear. No idea why these two attributes cause such a catastrophic failure.

Comment 28

[[e-mail]]

The sidebarObj.panels error happens because the shell integration dialog code tries to rebuild the sidebar, however the sidebar doesn't bother initialising itself if it's collapsed so there's nothing to rebuild. The dialog and rebuild run from a timeout so it's hard to see how it could affect anything else.

Comment 29

[Phoenix]

Reproducible on today trunk...