Hi kaufmann, I do appreciate you elaborating on the issue. However the table that it does create, are there any styling that might prevent it from what is being "handled" on the page? What function of the page is not working?

You gave a much better description than the earlier thread. It is true that Firefox renders tables somewhat differently than the older versions of IE that I imagine were the benchmark for creating the USPS site. However, I have not seen it myself and probably shouldn't speculate on it without laying hands on...

Okay, so I created a USPS account, and I see what you mean about the table. The thin blue scroll bar actually does allow you to show all the rows of the table, at least in my little test, even though it doesn't appear to go all the way to the bottom.

(This is not an ancient page design: the bar is drawn using SVG.)

Positioning the mouse pointer over the table and using the scroll wheel is a much easier way to scroll the table.

If you don't have a mouse with a scroll wheel, and the scroll bar isn't working for you, then it would be quite difficult to scroll the table.

Edit: I have hardware acceleration disabled on this system, which might affect how SVG is rendered.

> ... the table that it does create, are there any styling that might prevent it from what is being "handled" on the page? What function of the page is not working?

Great question, guigs2. As jscher2000 notes, the scroll bar is drawn using SVG (rather than leaving that function to the browser) and is, at least mostly, unusable - not just because the bar is very thin, but because it does not respond properly to trackpoint manipulation, or to clicking in the scroll bar - or for that matter to the screen-swipe style of iOS scrolling.

I created a USPS account, and I see what you mean about the table.

Thanks. As mentioned, I think that's the only way to understand the problem.

The thin blue scroll bar actually does allow you to show all the rows of the table, at least in my little test, even though it doesn't appear to go all the way to the bottom.

In my case - using trackpoint (on PC) or screen swipe (on iPad) - I can't go lower than the rows shown initially (and so, of course, can't go to the bottom). There is slight movement in the table, as if trying to respond to the scroll request, but then pops back up to the top of the table.

Positioning the mouse pointer over the table and using the scroll wheel is a much easier way to scroll the table.

I guess so (don't have that capability at present), but of course that method does not use the scroll bar IAC.

If you don't have a mouse with a scroll wheel, and the scroll bar isn't working for you, then it would be quite difficult to scroll the table.

Impossible, I find. I think that's why the prior thread had so many views.

I have hardware acceleration disabled on this system, which might affect how SVG is rendered.

I tried it with full acceleration and without acceleration on my thinkpad - no difference either way.

Thanks for thinking about this.

I'm not sure if all touchpads work the same, but... on a Windows 7 laptop with a non-touch screen, if I do a two-finger swipe down on the touchpad while the pointer is over the scrolling table, Firefox will scroll that element faster than the page so I can access the bottom rows. Not quite as clean as the scroll wheel, but there may be secret gestures I don't know.

... on a Windows 7 laptop with a non-touch screen, if I do a two-finger swipe down on the touchpad while the pointer is over the scrolling table, Firefox will scroll that element faster than the page so I can access the bottom rows. Not quite as clean as the scroll wheel, but there may be secret gestures I don't know.

I don't have any such luck, but then I'm not sure we should be trying to divine secret gestures IAC. :-) There is a scroll bar, and so far any work-arounds seem to depend on ignoring it to find an alternative scrolling method. The crux of the problem remains: Firefox cannot handle that scroll bar, while (some) other browsers can.

Actually, I still don't know why the scroll bar doesn't work for you. It work for me on a system with a mouse and with a touchpad. It certainly is narrow and on one system is twitches horizontally sometimes, but I think it should work.

Between us, I'm sure we have a lot of browser customizations and add-ons, so our results might not be typical. We should try to compare on clean set-ups. The first level test would be to try the page in Firefox's Safe Mode. That's a standard diagnostic tool to deactivate extensions, hardware accelerations, and some other advanced features of Firefox. More info: Diagnose Firefox issues using Troubleshoot Mode.

You can restart Firefox in Safe Mode using either:

• "3-bar" menu button > "?" button > Restart with Add-ons Disabled
• Help menu > Restart with Add-ons Disabled

Not all add-ons are disabled: Flash and other plugins still run

After Firefox shuts down, a small dialog should appear. Click "Start in Safe Mode" (not Reset).

Any difference?

Actually, I still don't know why the scroll bar doesn't work for you. It work for me on a system with a mouse and with a touchpad.

I don't know either, of course :-) - though FWIW, the number of view hits and "HAVE THIS PROBLEM" hits (in the prior thread) indicate that it doesn't work for a lot of people. It's possible that we all share some defect in our setups, but didn't you say that the mouse scrolled via its wheel, and the touchpad scrolled via a 2-finger swipe inside the table area - both work-arounds that avoid the scroll bar?

It certainly is narrow and on one system is twitches horizontally sometimes, but I think it should work.

In Chrome (to take an example of a browser that handles it), the bar is just as narrow - a small nuisance - but, once the cursor is on it, I can scroll it via trackpoint or trackpad (with no horizontal twitching).

... We should try to compare on clean set-ups. The first level test would be to try the page in Firefox's Safe Mode. ... Any difference?

I'm afraid not; it behaves the same as when add-ons are enabled.

What happens for me on my touchpad system is: I get the "pointer" mouse cursor when mousing over the blue bar, and I can click on it and scroll the contents as with any other scroll bar, but the bar doesn't move up and down in sync with the content being scrolled: it just stays put. If I do not slide straight down, the blue bar may twitch a pixel left or right.

Sorry, I cannot replicate this problem yet.

I get the "pointer" mouse cursor when mousing over the blue bar, and I can click on it and scroll the contents as with any other scroll bar, but the bar doesn't move up and down in sync with the content being scrolled: it just stays put. If I do not slide straight down, the blue bar may twitch a pixel left or right.

Great description! - sorry if you implied that earlier and I misunderstood, but I think that description adds crucial details:

• must hover over the blue part of the bar (representing the visible part of the table) and
• get the "selector" cursor (the pointing finger), then
• hold that click while scrolling (inside or outside of the table doesn't matter, as long as that click is held) to the needed table row, then
• release the click, and the table stays in place to allow a selection.

Most pages with an embedded scrollable input form (like the box I'm typing in on this page) do not change to the selector cursor when hovering over any part of the scroll bar, either blue (representing the visible part of the input form) or white (the invisible part of the input form). And it is common to click in the white part of the bar as a way of saying "show what is not visible". You can't do that with these USPS input forms, which behave differently.

Now, even with this method, that remains a very unintuitive (because the scroll bar does not reflect the position, and because the actual selections never get the "selector" cursor) and awkward way to work, so there is no visual feedback on either part of the operation.

And, I must try to understand why some browsers treat this differently. For example with Chrome (like Firefox), the cursor changes to "selector" in the blue part of the scroll bar, but not in the white part, but with Chrome (unlike Firefox): - a click in the white ("invisible") part of the scroll bar or - a drag on the blue ("visible") part of the scroll bar causes movement in the required direction - altogether more intuitive behavior.

Bottom line: At least there is a way to make this work with Firefox, but it is awkward, to say the least. It will require a lot more thought to think about:

• how and why some browsers handle these non-standard input forms with such intuitive behavior (that is, behavior that is familiar in more standard input forms),
• whether the fact that Firefox is less accommodating in that regard is a reportable bug, or whether Firefox should not have to worry about sites (like usps.com) that can't be bothered to comply with standards.

What do you think about those questions?

I think it would be good if someone could create a simplified test case that doesn't require a logon and filling out 10 form fields, particularly if we want to file a bug. Depending on my schedule, I might be able to do that over the weekend. However, since I never use SVG myself, I'm not sure I'll really understand it once I dive in...

Good point. This weekend Is shaping up to be very busy, but I will see what I can do. (I don't work in SVG either, but - though the bar is drawn in SVG - I will be surprised if that is the source of the problem.)