373078 - menu scroll arrows missing (bug 245163 has regressed)

Status: RESOLVED WONTFIX

(Core :: XUL, defect)

Description

[Tony Mechelynck [:tonymec]]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3pre) Gecko/20070307 BonEcho/2.0.0.3pre
Build Identifier: "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3pre) Gecko/20070307 BonEcho/2.0.0.3pre" - Build ID: 2007030704

Even with long menus, clipped at the screen edge, top and bottom scroll arrows are now omitted. (Regression to bug 245163 )

Reproducible: Always

Steps to Reproduce:
1. Click an image link near the (vertical) middle of the viewport, especially with large chrome fonts and/or many extensions in place.

Actual Results:  
The menu extends from the mouse pointer to the opposite (top or bottom) edge of the screen, no further. Even if part of the menu is hidden, scroll arrows are now absent.


Expected Results:  
Long menus should have arrows at top and bottom to allow scrolling.


Additional info: See the two attachments which I'm going to add as soon as this bug gets submitted. They display the same context menu, once with the mouse pointer near the middle, the other time with the mouse pointer near the bottom edge of the viewport.

Comment 1

[Tony Mechelynck [:tonymec]]

Sorry, the files won't attach. I've uploaded them here:
- clipped menu with mouse pointer near the middle:
http://users.skynet.be/antoine.mechelynck/other/menuclip.png
- the same menu, but triggered with the mouse near the edge of the viewport:
http://users.skynet.be/antoine.mechelynck/other/menulong.png

Comment 2

[Tony Mechelynck [:tonymec]]

(In reply to comment #0)
[...]
> 1. Click an image link [...]

Oops... I should have said "Right-click" of course.

Comment 3

[Tony Mechelynck [:tonymec]]

adding cc to bzbarsky (author of the patch to bug 245163 )

Comment 4

[Boris Zbarsky [:bzbarsky]]

So are you saying it's a regression caused by the checkin for bug 245163?  Or a regression where things worked after bug 245163 got checked in but no longer work now?

Comment 5

[Tony Mechelynck [:tonymec]]

(In reply to comment #4)
> So are you saying it's a regression caused by the checkin for bug 245163?  Or a
> regression where things worked after bug 245163 got checked in but no longer
> work now?
> 

The latter: I'm saying the _fix_ to bug 245163 doesn't work anymore.

Comment 6

[Boris Zbarsky [:bzbarsky]]

OK.  It it broken on trunk also?  Or only on branch?

Can you possibly narrow down when it stopped working (using builds from archive.mozilla.org as needed)?

I'm not going to have significant time to spend on this for months, so whatever help you can provide is very much appreciated...  Once we find out who broke this, we cc them.  ;)

Comment 7

[Tony Mechelynck [:tonymec]]

(In reply to comment #6)
> OK.  It it broken on trunk also?  Or only on branch?

I don't know: I don't use trunk Firefox, and on trunk SeaMonkey I don't have enough extensions for my context menus to be long enough to show the bug.

> 
> Can you possibly narrow down when it stopped working (using builds from
> archive.mozilla.org as needed)?

OK. I'm trying earlier nightly builds in backwards succession from ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2007-??-??-??-mozilla1.8 but it takes some time -- loading mostly: maybe I should save my session and try with only one or two tabs. I haven't yet because I thought I would only have to go back a few days. Soon's I find "between which builds" the bug surfaced, I'll add a further comment here below.

> 
> I'm not going to have significant time to spend on this for months, so whatever
> help you can provide is very much appreciated...  Once we find out who broke
> this, we cc them.  ;)
> 

No prob.

Comment 8

[Boris Zbarsky [:bzbarsky]]

> OK. I'm trying earlier nightly builds in backwards succession

For what it's worth, doing a binary search between known-broken and known-working builds should work pretty fast...  e.g. if you jump back a month or so and that works, it shouldn't take more than 5 downloads to pin down the date.

Comment 9

[Tony Mechelynck [:tonymec]]

(In reply to comment #8)
> > OK. I'm trying earlier nightly builds in backwards succession
> 
> For what it's worth, doing a binary search between known-broken and
> known-working builds should work pretty fast...  e.g. if you jump back a month
> or so and that works, it shouldn't take more than 5 downloads to pin down the
> date.
> 

Yes, of course. I thought the scrolling menus had worked no more than a week ago, but I've backtracked to Feb.19 already and all tested builds exhibit the bug.

It cannot be something in the install directory, because I always use "rm -Rvf /usr/local/firefox" just before untarring the nightly archive into /usr/local (which recreates the just-removed directory tree). Do you think it could be something in my profile, and if yes, what? Nothing in about:config rings a bell with me (but of course, maybe I don't know what to filter on. I've tried "scroll", "menu", "arrow", "context".)

Notes:
1. I fear that running in safe mode would, by suppressing menu items pertaining to extensions, make my context menus too short to test for presence vs. absence of the bug.
2. ls -l `which firefox` gives the expected value
lrwxrwxrwx 1 root root 18 may 16 2006 /usr/local/bin/firefox -> ../firefox/firefox*
(where the star at the end means "executable")

Comment 10

[Boris Zbarsky [:bzbarsky]]

Does a Jan 1 build show the problem?  What about Oct 1?

I can't thunk of any preferences that would affect this...

Comment 11

[Tony Mechelynck [:tonymec]]

(In reply to comment #10)
> Does a Jan 1 build show the problem?  What about Oct 1?
> 
> I can't thunk of any preferences that would affect this...
> 

The oldest Fx2/Linux build, which is a Jan.2 build, viz. "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2pre) Gecko/20070102 BonEcho/2.0.0.2pre" - Build ID: 2007010204 - shows the bug. I'm gonna try the oldest Fx1.5 build next.

Comment 12

[Tony Mechelynck [:tonymec]]

Sorry, Jan.2 isn't the oldest, but ftp.mozilla.org/blahblah/nightly has no Fx builds at all between 24-Nov-2005 and 1-Jan-2007 (excluded). According to bug 245163 comment #121 the fix was landed on Fx1.5 not later than 29-Oct-2005 so November 2005 builds should have the fix. _That's_ what I'm gonna try now.

Comment 13

[Boris Zbarsky [:bzbarsky]]

There should be older builds at http://archive.mozilla.org/pub/firefox/nightly/

Comment 14

[Tony Mechelynck [:tonymec]]

(In reply to comment #13)
> There should be older builds at http://archive.mozilla.org/pub/firefox/nightly/
> 

Yes, I found them. Reposting a comment rejected because of mid-air collision:

Problem does not affect Fx1.5 builds: I have tested 1.5 (Build ID: 2006010104) and 1.5.0.11 (Build ID: 2007030904) and neither has the problem. Going back to 2006 builds of Fx2 from the "archive" site.

Comment 15

[Tony Mechelynck [:tonymec]]

Gotcha! -- and I'm surprosed by the result, but here they are:

- Firefox 1.5 (including the latest 1.5.0.11) is not affected
- In the Fx2 branch, the bug appeared between 2006-07-06-04 and 2006-07-07-04 Linux builds
- Whether the current theme is the default or the GreyModern theme does not affect the result (in particular, the two "edge" cases above were tested with the default theme).

What surprises me is that I would have sworn that I've seen menu arrows last week in the latest Fx2 nightlies, but I can't get them back.

Now I'm gonna investigate Minefield builds...

Comment 16

[Tony Mechelynck [:tonymec]]

So:
- The current trunk Firefox (Minefield 3.0a3 2007030904) exhibits the bug
- On the trunk, the bug appears between (Minefield 3.0a1) 2006-07-03-04 and 2006-07-04-04.

Updating flags to reflect what I discovered.

Comment 17

[Boris Zbarsky [:bzbarsky]]

Branch range:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-07-06+04&maxdate=2006-07-07+04&cvsroot=%2Fcvsroot

Trunk range:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-07-03+04&maxdate=2006-07-04+04&cvsroot=%2Fcvsroot

On trunk, the only changes that look at all relevant are the theme changes.

But those didn't land on the branch in the given range.

I assume you're sure about those regression ranges?

Comment 18

[Tony Mechelynck [:tonymec]]

(In reply to comment #17)
> I assume you're sure about those regression ranges?

I tested the "margin cases" mentioned above in comment #15 and in comment #16 as well as a number of other builds both before and after, including all three "latest" builds (dated 9-Mar-2007):

- In the Fx1.5 branch, all builds tested had menu scroll arrows.
- In the Fx2 (BonEcho) branch, builds <= 2006070604 had scroll arrows, builds >= 2006070704 didn't.
- In the Fx3 (Minefield=trunk) branch, I tested the latest build, then backward from 2006070704. 2006070404 and all later builds lacked scroll arrows, 2006070304 didn't. After the latter, I tested the July 4 build again and it again lacked scroll arrows
- BonEcho 2.0b2 (2006090104) was tested with both the default and GreyModern themes, other builds were tested with one or the other; in no case did I see anything to let me think that changing the theme might make the bug appear or disappear.
- BonEcho & Minefield "edge cases" were tested with the default theme.

So, yes, I feel certain about those regression ranges; but since /testis unus, testis nullus/ (Latin, wfw: one witness [is] no witness), someone else should check me and try to reproduce the problem: "when the context menu (including items added by extensions) is longer than the distance from the mouse pointer to the farthest (top or bottom) edge of the *display* (not the Fx window), the menu is chopped at one end and cannot be scrolled, because the scroll arrows introduced by the fix to bug 245163 are absent".

The detailed log of which builds I tested, in which order, and with which theme, has just been uploaded to http://users.skynet.be/antoine.mechelynck/other/b373078.txt

Comment 19

[Tony Mechelynck [:tonymec]]

bug 349918 (landed-on-branch on or near incriminated range) won't open to me -- I guess it has security implications.

bug 343097 is about scrollboxes; it was landed-on-trunk on or very near the incriminated range; it was landed-on-branch but I don't see when.

bug 342841 (trunk) / bug 318168 (branch) is about disabling arrows; was landed-on-trunk on or near incriminated range. Attachment 228077 [details] [diff] to the latter seems to include both "scrollbox" and "tabbrowser" fixes. Don't know when landed on branch.

Hm. Nothing very conclusive, and nothing "obviously in both ranges".

Comment 20

[Boris Zbarsky [:bzbarsky]]

ccing Neils.  ;)

Comment 21

[[e-mail]]

Attachment: My screenshot

Note: I disabled the context menu code that normally hides irrelevant items.

Comment 22

[Tony Mechelynck [:tonymec]]

(In reply to comment #21)
> Created an attachment (id=259110) [details]
> My screenshot
> 
> Note: I disabled the context menu code that normally hides irrelevant items.
> 

Hm. I see menu arrows in a home-built version of SeaMonkey.

- Would you mind posting the user-agent string of that build (as found e.g. just below the "version link" in the about: page)? (Trunk or branch, and which branch? Which OS platform?)

- Would you mind posting, as a unified diff, the changes you made in the source to "disable the context menu code that hides irrelevant items", so that the gurus could look these changes over and see if and how they can use all or part of these changes to fix the present bug without regressing some other bug?

As said above, I'm seeing the present bug on Linux, in Fx2 and in trunk builds of Firefox, but not in Fx1.5; for the record, the current Fx1.5 build I'm using (and which doesn't exhibit this bug) is:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.11pre) Gecko/20070319 Firefox/1.5.0.11pre

Comment 23

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #22)
> - Would you mind posting, as a unified diff, the changes you made in the
> source to "disable the context menu code that hides irrelevant items", so that 
> the gurus could look these changes over and see if and how they can use all or
> part of these changes to fix the present bug without regressing some other
> bug?

Neil is one of "the gurus" :). The changes he mentions were made so that he could reproduce the "too long context menu" issue, and demonstrate that the solution implemented in bug 245163 still works for him.

From your comment, and your regression range, it sounds like you think the presence of the arrows is the bug. The bug is in fact the opposite: the original reporter is complaining that he no longer gets arrows. Neil's comment and screenshot was a "WFM".

Comment 24

[:Gavin Sharp [email: [e-mail]]]

Oh, now I'm confused. You're the original reporter. I don't understand your comment 22, in that case. Can you clarify what you think the bug is, and what you mean by "I see menu arrows in a home-built version of SeaMonkey"?

Comment 25

[Tony Mechelynck [:tonymec]]

(In reply to comment #24)
> Oh, now I'm confused. You're the original reporter. I don't understand your
> comment 22, in that case. Can you clarify what you think the bug is, and what
> you mean by "I see menu arrows in a home-built version of SeaMonkey"?
> 

The bug is indeed the absence of menu scroll arrows in recent builds of Firefox 2 and 3a. They are still present in Fx1.5, which is what I mean by saying that "my current Fx1.5 build does not exhibit the bug".

What I mean by the sentence "I see menu arrows in a home-built version of SeaMonkey" is: I see (in attachment #259110 [details]) menu arrows (i.e., I see menus having arrows at top and bottom, thus not exhibiting the bug) in an instance of SeaMonkey (the "suite" program, successor to the Mozilla Suite, and thus not Firefox) which was built from source, not downloaded as a binary from the Mozilla site (as demonstrated from the fact that the datestamp, partially covered by the menu, is all zeros, or at least starts with 0000 and not 2007). I notice the sentence "I disabled the context menu code that hides irrelevant items" in comment #21. This sentence made me think that the build in question was built from modified sources, and I suspect that the modifications required to "disable the context menu that hides irrelevant items" would also un-hide the context arrows, thus fixing the bug, but also apparently regressing bug 342619. I absolutely need arrows whenever the menu is partly cut off, as it is at the moment when I click on a link which is also an image, about halfway between the top and bottom of the screen (see the screenshots linked from comment #1). I don't need those same arrows when the menu is fully displayed. Thus I want a fix for this bug, but I would prefer a fix that wouldn't break any fix for bug 342619.

Is that clear? If it isn't, I don't know how to make it clearer.

Comment 26

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #25)
> I notice the sentence "I disabled the context menu code that hides irrelevant
> items" in comment #21. This sentence made me think that the build in question
> was built from modified sources, and I suspect that the modifications required
> to "disable the context menu that hides irrelevant items" would also un-hide
> the context arrows, thus fixing the bug, but also apparently regressing bug
> 342619.

Ah, well that's the misunderstanding, then. The code he changed doesn't do anything to the arrows, it just disables the hiding of the other normal menu items so that the context menu would be long enough to trigger the overflow behavior.

Comment 27

[Tony Mechelynck [:tonymec]]

P.S. (to comment #25) Closer inspection of attachment #259110 [details] shows that Neil is running on Windows. I'm on Linux. The difference may or may not be relevant. I'm changing the "Hardware/OS" qualification of this bug, just in case.

Comment 28

[[e-mail]]

OK, just to clarify:
a) yes, that was a self-build of SeaMonkey trunk Windows
b) yes, the change simply ensures that there are lots of menuitems
c) I don't see the problem in the SeaMonkey 1.1.1 release
d) I don't see the problem in a Linux 1.9a2 self-build
   (my Linux isn't new enough to run later builds)

Comment 29

[Tony Mechelynck [:tonymec]]

(In reply to comment #28)
[...]
> c) I don't see the problem in the SeaMonkey 1.1.1 release
> d) I don't see the problem in a Linux 1.9a2 self-build
>    (my Linux isn't new enough to run later builds)
> 

Strange: on Linux I see the problem in all builds (or at least all that I tested) of Minefield 3.0 a2 and a3 as well as in 3.0a1 builds dated 4 July 2006 and later. In BonEcho I see it from 7 July. All of these, installed from the .tar.gz archives downloaded from ftp.mozilla.org or archive.mozilla.org. Could it be something which is handled differently in Firefox and SeaMonkey? Then we would have to reclassify it elsewhere than in "Core".

I hope it isn't due to a difference in non-Mozilla libraries such as the GTK2 libs etc. (My current OS is openSUSE 10.2; recent trunk builds of SeaMonkey wouldn't load on my earlier Novell-SUSE Professional 9.3).

Comment 30

[Daniel Veditz [:dveditz]]

Not blocking on this polish bug (that apparently happened long long ago), but if you get a safe trunk-tested fix we'll consider it.

Comment 31

[:Gavin Sharp [email: [e-mail]]]

Attachment: another screenshot (WFM)

(In reply to comment #30)
> Not blocking on this polish bug

This isn't a polish bug. This bug is saying that bug 245163 has regressed completely, which means that long context menus get cut off and the items at the end can't be used.

That being said, I can't reproduce with a 1.8 branch Windows Firefox build from 20070308. Here's my screenshot.

Tony: Have all of the builds you've tested used the same profile? I can walk you through modifying a build to get the long context menus, if you want, so that you can try a new profile.

Comment 32

[:Gavin Sharp [email: [e-mail]]]

dveditz: see comment 31.

Comment 33

[Tony Mechelynck [:tonymec]]

(In reply to comment #31)
[...]
> Tony: Have all of the builds you've tested used the same profile? I can walk
> you through modifying a build to get the long context menus, if you want, so
> that you can try a new profile.

Yes, they have. If the instructions are bulky, send them by private email.

Comment 34

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #33)
> (In reply to comment #31)
> [...]
> > Tony: Have all of the builds you've tested used the same profile? I can walk
> > you through modifying a build to get the long context menus, if you want, so
> > that you can try a new profile.
> 
> Yes, they have. If the instructions are bulky, send them by private email.

I forgot to ask: SeaMonkey or Firefox?

Comment 35

[Tony Mechelynck [:tonymec]]

(In reply to comment #34)
> (In reply to comment #33)
> > (In reply to comment #31)
> > [...]
> > > Tony: Have all of the builds you've tested used the same profile? I can walk
> > > you through modifying a build to get the long context menus, if you want, so
> > > that you can try a new profile.
> > 
> > Yes, they have. If the instructions are bulky, send them by private email.
> 
> I forgot to ask: SeaMonkey or Firefox?
> 

I have both but, as can be seen from comment #0, comment #15 and comment #16, it's in Firefox (or more precisely, in BonEcho and Minefield but not in Fx1.5) that I noticed the bug.

Comment 36

[Tony Mechelynck [:tonymec]]

After using Fx1.5 for some time, I decided to try BonEcho again today:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4pre) Gecko/20070328 BonEcho/2.0.0.4pre
(Build ID: 2007032804)

- Left-click menus in chrome (such as the Tabs menu added on the menu bar by the "Tabs Menu" extension, or the "Search Engines" menu obtained by left-clicking the G-for-Google next to the Search bar) have the arrows when they overflow the screen height.
- Right-click menus in content lack them, even when clipped because they overflow the distance between the mouse pointer and the top or bottom of the screen.

This is on the pristine Mozilla build, without the hack which Gavin sent me by private email to display all possible menu items.

Comment 37

[Boris Zbarsky [:bzbarsky]]

Per comment 32...

Comment 38

[Tony Mechelynck [:tonymec]]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4pre) Gecko/20070329 BonEcho/2.0.0.4pre
(Build ID: 2007032904)

- Like yesterday, chrome menus have arrows only when too long for the screen.
- But content right-click menus now always have arrows, even when they're not too long.

I wonder what changed between yesterday and today...

Comment 39

[Daniel Veditz [:dveditz]]

Is anyone other than Tony seeing this problem on Linux?

Tony: did you say whether or not you tried with a new profile? Don't know what might affect this (extensions?) but still worth eliminating as a possibility.

Just to be clear, you're saying FF2.0.0.4pre is now OK and doesn't need a fix?

Comment 40

[Tony Mechelynck [:tonymec]]

(In reply to comment #39)
> Is anyone other than Tony seeing this problem on Linux?
> 
> Tony: did you say whether or not you tried with a new profile? Don't know what
> might affect this (extensions?) but still worth eliminating as a possibility.

I tried a virgin profile with Minefield a few days ago and the results looked neither better not worse than with my usual profile. They were harder to interpret though, because with no extensions and few tabs it's harder to make sure that a context menu is longer than half the 1024px height of my screen.

> Just to be clear, you're saying FF2.0.0.4pre is now OK and doesn't need a fix?

I'm saying it appears to be OK; but since I don't know whether something has changed in the build (and what), or whether I unwittingly did something (and what) which, as a side-effect, made the bug disappear, I'm reserving judgment about whether this bug report can be closed or not.

But yes, at the moment, and until proof of the contrary, the bug seems to have disappeared from Firefox (BonEcho) 2.0.0.4pre builds datestamped 2007032904 or later.

I shall go on using BonEcho nightlies for day-to-day browsing and, if the bug doesn't reappear, I suggest to resolve it WFM after a suitable length of time. In the meantime, I may try a Minefield build from time to time (between closing one build of BonEcho and installing the next) to check whether I still experience the bug on trunk builds.

Comment 41

[Tony Mechelynck [:tonymec]]

(In reply to comment #40)
> [...] the 1024px height of my screen. [...]

Oops: 1024 is the width. I should have said "the 768px height of my screen".

Comment 42

[Tony Mechelynck [:tonymec]]

The current Fx trunk nightly (with a one-line patch to chrome/browser.jar/content/browser/nsContextMenu.js to make the context menu very long) has the arrows in the "clean" profile. In my "default" profile it has them too but for some reason Tab Mix Plus session restore doesn't work.

IOW I cannot reproduce the bug on the current Minefield nightly.

Comment 43

[Tony Mechelynck [:tonymec]]

dveditz: I notice that Bugzilla thinks I reverted your blocking 1.8.1.4+ to ?. That was never intentional. However after comment #40 and comment #42 the blocking may have become a moot point...

Comment 44

[Daniel Veditz [:dveditz]]

OK, not blocking for now.

Comment 45

[Tony Mechelynck [:tonymec]]

Bug has not reappeared since I wrote comment #40 

=> WFM

Anyone sees this bug again, please reopen and/or comment.

Comment 46

[Tony Mechelynck [:tonymec]]

I'm seeing this bug again under heavy load (174 tabs, Fx using approx 80% CPU without renicing) in "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4pre) Gecko/20070412 BonEcho/2.0.0.4pre" - Build ID: 2007041204. Like in comment #36, context menus in content lack the arrows, long chrome menus ("Tabs" on the menu bar, or G-for-Google "Search engines" menu) have them. (With 2G of RAM I think I can afford that many tabs.)

The corresponding version of Minefield doesn't exhibit the bug on the "Congratulations! You've successfully installed a trunk version" page (but no other tab loaded).

Not sure which build was "the first" with the bug again (been away from home for several days).

I tried loading BonEcho & Minefield on swapped profiles (B on M's profile and vice-versa), but results were inconclusive either way (i.e. the menus weren't long enough). (Didn't apply the "show all possible menu items" hack.)

After noticing the return of the bug, had an X error message for the program "Gecko" followed by crashes (without Talkback) for all of BonEcho, Thunderbird, SeaMonkey and finally Xorg. After "telinit 3" followed by "telinit 5" (to make sure X was restarted cleanly), BonEcho still exhibits the bug.

Comment 47

[Tony Mechelynck [:tonymec]]

...and in BonEcho 2007041304 the arrows are back, even when the context menu is not too long. Same profile as for comment #46, but started before SeaMonkey 1.5a rather than after it. I'm more and more puzzled.

I seem to be farther than ever from a "systematically reproducible" testcase. All I can say ATM is that heavy load conditions seem to be an aggravating factor.

Gecko is not shared between various Mozilla products running in parallel, is it? (Possibilities on my machine currently are Tb2, Fx2, Sm1.5a and "Fx3a -no-remote" meaning twice 1.8.1.4pre and twice 1.9a4pre at the most.)

Comment 48

[Tony Mechelynck [:tonymec]]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4pre) Gecko/20070420 BonEcho/2.0.0.4pre - Build ID: 2007042004

...arrows missing again:
- in chrome menus they appear (as always); after a couple of seconds though
- in right-click menus in content they aren't there, even after more than a minute

Comment 49

[Tony Mechelynck [:tonymec]]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4pre) Gecko/20070506 BonEcho/2.0.0.4pre - Build ID: 2007050603

arrows remained missing until yesterday; today I have them again.

I can't see anything different in how I used Firefox to get them or not. AFAICT they're either present or absent for the whole session (from installing one nightly to closing it in order to install the next day's version). Race condition at some critical point during browser startup perhaps?

I define "browser startup" (in the context of the above sentence) as whatever happens between clicking on the Fx icon and when all extensions are running and all "tabs from last time" loaded. No user intervention except sometimes to confirm extension upgrades or crashed-session reload. I wonder whether those mid-startup alerts could make a difference. Maybe I should start playing with "browser.startup.homepage_override.mstone" in prefs.js between unloading and reloading Firefox, to force an extension check (with alert) and see if it makes the arrows come back. I'll do that next time the arrows go away.

Comment 50

[Tony Mechelynck [:tonymec]]

(In reply to comment #49)
[...]
> Maybe I should start playing with
> "browser.startup.homepage_override.mstone" in prefs.js between unloading and
> reloading Firefox, to force an extension check (with alert) and see if it makes
> the arrows come back. I'll do that next time the arrows go away.
> 

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4pre) Gecko/20070507 BonEcho/2.0.0.4pre - Build ID: 2007050703

They have already gone away; and yet, the browser was loaded at a relatively "quiet" time and auto-updated one extension (with confirm prompt before & after) at startup. :-(

Comment 51

[Tony Mechelynck [:tonymec]]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4pre) Gecko/20070512 BonEcho/2.0.0.4pre - Build ID: 2007051203

Arrows are back. ?:-)

Comment 52

[Tony Mechelynck [:tonymec]]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4pre) Gecko/20070519 BonEcho/2.0.0.4pre - Build ID: 2007051903

Arrows are gone again. :-(

Comment 53

[Tony Mechelynck [:tonymec]]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4pre) Gecko/20070522 BonEcho/2.0.0.4pre - Build ID: 2007052203

arrows were still gone yesterday, but today they're back.

Comment 54

[Tony Mechelynck [:tonymec]]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4pre) Gecko/20070523 BonEcho/2.0.0.4pre - Build ID: 2007052303

...and today they're gone again.

Comment 55

[Tony Mechelynck [:tonymec]]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4pre) Gecko/20070524 BonEcho/2.0.0.4pre - Build ID: 2007052403

arrows are back

Comment 56

[Tony Mechelynck [:tonymec]]

Let's recap. There must be /some/ reason why sometimes I see the arrows and sometimes I don't; but I can't see any pattern.

- Every day I install the next BonEcho nightly from the .tar.gz archive to a "clean" location, as follows:

    gunzip firefox*.gz
    rm -Rvf /usr/local/firefox
    tar -xvC /usr/local -f firefox*.tar

- Some days I see menu arrows in the right-click menu in content, other times I don't, even when clicking lower down on the same image link unveils a different number of menu items, showing that arrows are needed.
- Long menus in chrome always have arrows when needed.
- I can't remember ever seeing arrows both present and absent at different times on a single build.
- From one day to the next, arrows seem to appear and disappear randomly, even though the number and content of my tabs is similar, and varies in a constant direction (currently reducing the number of tabs between one day and the next), the theme is the same, and extensions don't change (other than by auto-update, which doesn't appear to be correlated with presence/absence of arrows AFAICT).

***** Am I really the only user who sees this regression ????? *****

Comment 57

[Tony Mechelynck [:tonymec]]

(In reply to comment #56)
[...]
> - I can't remember ever seeing arrows both present and absent at different
> times on a single build.
[...]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4pre) Gecko/20070525 BonEcho/2.0.0.4pre - Build ID: 2007052503

This build initially installed "with arrows". After a reload for extension upgrade, the arrows were gone. Reload again, they were back.

Comment 58

[Tony Mechelynck [:tonymec]]

*** Workaround ***

Don't know if there is a relation, but a few days ago, I added the following to <myFirefoxProfile>/chrome/userChrome.css and since then, not only do my menus get scrollbars when necessary, the scrolling arrows at top and bottom haven't disappeared either.

/*
 * give the menus a scrollbar when they are too high to be
 * displayed in full
 */
menupopup scrollbox, #contentAreaContextMenu scrollbox
  { overflow-y:         auto            !important
  }
/*
 * uncomment the following to
 * eliminate scroll buttons at top and bottom of the menus
 *
menupopup autorepeatbutton, #contentAreaContextMenu autorepeatbutton
  { display:            none            !important
  }
 */

Comment 59

[Tony Mechelynck [:tonymec]]

I'm uncommenting the 2nd CSS rule mentioned in comment #58 above, meaning I won't notice this bug anymore.

I'm marking this bug WONTFIX; anyone gets bitten by it, or wants to try and fix it, please REOPEN.