User-Agent: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.2.1) Gecko/20021201 Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.2.1) Gecko/20021201 After loading the URL, make sure the window is large enough to avoid having a scrollbar on the bottom part of the page (which defaults to showing the latest memory prices). Then press CTRL-+ to increase the font size to the point where a scrollbar becomes necessary again. A dark gray line appears in place of the scrollbar. Click in the middle of the line. The links in the bottom pane are then all disabled, and remain so until the page is reloaded, even if the fonts are zoomed back out to get rid of the half-formed scrollbar. Since I reproduced it in 1.2.1 in OS/2, 1.2.1 in Linux, and 1.3a in OS/2, I'm inclined to think it's not version specific. Reproducible: Always Steps to Reproduce:

I can't reproduce this in 2002121308 Linux or 2002121312 OS/2 trunks. Are you using userChrome.css or userContent.css?

related: bug 173072 Can reproduce on a current CVS, linux, and I don't have to scale down again to "disable" the links in the lower frame. Just click around the middle / lower half of the vertical ghosted scrollbar a few times. After a few clicks the links in the bottom frame are no longer indicated as links.

actually.. it isn't only that links that are disabled: the text in the lower frame can't be selected.

Maybe I can't reproduce this because my userContent.css doesn't permit Pricewatch's microscopic fonts in the first place. When I grow the fonts to produce the horizontal scroll the fonts become gigantic, around 2em-3em, having started at >.9em.

I have a minimum font size of 14 specified, which is small enough that the pricewatch fonts aren't affected. If I increase this to 16, I can still reproduce the problem by maximizing my window (on a 1280x1024 desktop) and zooming the text. I also just noticed that the links aren't completely dead, just mostly dead. If you right-click on the link text, you can open it in a new tab or window. I have a hunch that if the process to create a new scrollbar were properly completed, the defective link problem would go away, because if you resize the window to force a bottom scrollbar, everything works.

Unable to reproduce this bug in a build with the fix for bug 173072 (fix was checked in an hour after comment 2 was added)

Apologies if this is (ever so slightly) off topic but I can reproduce a very similar problem under Win2K for both Phoenix and Mozilla. When resizing the font size, if I make it so small that the (vertical) scrollbar is no longer necessary (and, hence, disappears), then make it larger again, necessitating a scrollbar, the scrollbar 'background' appears, in a different colour from the 'normal' background and neither the scrollbar itself nor the top and bottom arrows appear. Clicking on the scrollbar has no effect and I have not (yet) been able to make the scrollbar reappear. This only affects the current tab. As a point of interest, the pointer behaves a bit 'funny' when passing over this 'empty' scrollbar - when moving the pointer from outside of the window, to a point within it, passing over the scrollbar, the pointer changes to an East-West resize pointer and does not change back (e.g. when hovering over a link) until it exits the window.

to comment 7: That sounde like a completely different bug. Which build ID?

I think it's related enough to the first comment about the disappearing scrollbar to be relevant here. Phoenix 0.5 [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021207 Phoenix/0.5] Mozilla 1.2 [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2) Gecko/20021126]

Resolving as duplicate of bug 173072. Builds later than Dec. 14th, 2002, should have the fix. General note: Please always make sure you can reproduce a bug with a build no more than three days old, before filing bugs on it. See the bug reporting guidelines. *** This bug has been marked as a duplicate of 173072 ***

Your general note isn't applicable here. The fix was not checked in (much less in the nightly builds) until after I filed my report. I had verified its existence in 1.3a (dated 12-13-2002) before reporting the bug.

Hey, guys, let's not fight here! :) I think the point was aimed at my comment and I hold my hands up for not realising this bug had already been fixed. Thanks for the fix, R.K.Aa - apologies once more.

verified.