On a page that is generated by javascript, scrollbars do not appear when necessary.
Created attachment 16224 [details] Testcase containing 50 lines of text to demonstrate bug
This bug was inspired by Bug 55330.
This bug may be a duplicate of 53683 These are VERY similar. That bug adds one other thing, which is adding dynamic content to a new window. Right now, the new window isn't displaying anything which needs to be fixed before this bug's behavior can be seen there. Read my notes on that bug because I somewhat pinpointed a date in builds where this behavior was working correctly and it isn't in the too distant past. Jake
guessing jst, since script is required to see the bug
confirmed WinNT commercial build id 2000100608 upgrading severity to major and priority to P2 because it makes sites that use this technique unusable. there doesn't seem to be any way to get a vertical scrollbar to appear.
per jst and my own opinion, nominating for rtm. eric seems like he's usually involved with scrolling issues, assigning to him. Per jst: "I don't believe it's a DOM problem at all, the DOM code simply modifies the document hierarchy, layout should make scrollbars appear if they're needed. "
*** Bug 55330 has been marked as a duplicate of this bug. ***
*** Bug 56064 has been marked as a duplicate of this bug. ***
Requesting a triage on this bug. It's nominated but doesn't have a - or +. Are we going to fix this for rtm ?
rtm need info: how common is this in the top 100 sites?
Lest anyone forget my commnets from 9-22 in bug 53683 : "this seems to be a regression. I confirmed it as working in build: 2000091505" It just seems like someone can figure out why it is working there and make the changes needed to make it work in Trunk builds and RTM. Also, I'm not sure that you will find this problem on the top 100 sites, since most of those are pretty conservative with javascript. However, it is going to piss off a TON of web developer who have been waiting for Netscape to come out with a DHTML capable browser. If the developers don't like your browser, all the sites will continue to be pretty slanted toward proprietary IE functionality. I think that is all the reason you need to fix this! Jake
This happens because javascript sets the document of the scrollbars to nsnull. The stack trace is at the bottom. You will find that aDocument passed in is nsnull. You can reproduce this stack trace in the following way: 1) Open the test case given in this example in the browser 2) put a break point on line 436 of nsGfxScrollFrame.cpp ( 3) hit reload to cause the page to layout again 4) When you hit the breakpoint Look at the address of "content" this is the vertical scrollbar content node. Write it down. 5) Place a conditional breakpoint in "nsXULElement::SetDocument" that is the following: "this == <the address of content you wrote down>" 6) Hit continue. You will hit this break point. And see that it is setting the scrollbars document to nsnull. This is why the scrollbars do not work. Reassigning to someone who knows the dom. nsXULElement::SetDocument(nsXULElement * const 0x0408f690, nsIDocument * 0x00000000, int 1, int 1) line 2157 nsBindingManager::ChangeDocumentFor(nsBindingManager * const 0x0407e150, nsIContent * 0x040706b8, nsIDocument * 0x040aebe0, nsIDocument * 0x00000000) line 362 nsGenericElement::SetDocument(nsIDocument * 0x00000000, int 1, int 1) line 1235 nsGenericHTMLElement::SetDocument(nsIDocument * 0x00000000, int 1, int 1) line 907 + 20 bytes nsHTMLHtmlElement::SetDocument(nsHTMLHtmlElement * const 0x040706b8, nsIDocument * 0x00000000, int 1, int 1) line 63 + 26 bytes nsDocument::Reset(nsIChannel * 0x033af0c0, nsILoadGroup * 0x03389fc0) line 886 nsHTMLDocument::Reset(nsIChannel * 0x033af0c0, nsILoadGroup * 0x03389fc0) line 390 + 16 bytes nsHTMLDocument::OpenCommon(nsIURI * 0x040e6d70) line 2071 + 32 bytes nsHTMLDocument::Open(nsHTMLDocument * const 0x040aecc8, JSContext * 0x02c7d400, long * 0x00f09f1c, unsigned int 1) line 2147 + 18 bytes NSHTMLDocumentOpen(JSContext * 0x02c7d400, JSObject * 0x00f9a8e0, unsigned int 1, long * 0x00f09f1c, long * 0x0012e134) line 876 + 35 bytes js_Invoke(JSContext * 0x02c7d400, unsigned int 1, unsigned int 0) line 790 + 23 bytes js_Interpret(JSContext * 0x02c7d400, long * 0x0012ec44) line 2589 + 15 bytes js_Invoke(JSContext * 0x02c7d400, unsigned int 1, unsigned int 2) line 807 + 13 bytes js_InternalInvoke(JSContext * 0x02c7d400, JSObject * 0x00e0e1f0, long 16360528, unsigned int 0, unsigned int 1, long * 0x0012eddc, long * 0x0012ed6c) line 879 + 20 bytes JS_CallFunctionValue(JSContext * 0x02c7d400, JSObject * 0x00e0e1f0, long 16360528, unsigned int 1, long * 0x0012eddc, long * 0x0012ed6c) line 3193 + 31 bytes nsJSContext::CallEventHandler(nsJSContext * const 0x02c7d5b0, void * 0x00e0e1f0, void * 0x00f9a450, unsigned int 1, void * 0x0012eddc, int * 0x0012edd8, int 0) line 907 + 33 bytes nsJSEventListener::HandleEvent(nsIDOMEvent * 0x04078684) line 154 + 64 bytes nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x0407e370, nsIDOMEvent * 0x04078684, nsIDOMEventTarget * 0x02c7d630, unsigned int 1, unsigned int 7) line 788 + 19 bytes nsEventListenerManager::HandleEvent(nsIPresContext * 0x0406fef0, nsEvent * 0x0012f32c, nsIDOMEvent * * 0x0012f2f0, nsIDOMEventTarget * 0x02c7d630, unsigned int 7, nsEventStatus * 0x0012f350) line 1365 + 39 bytes GlobalWindowImpl::HandleDOMEvent(GlobalWindowImpl * const 0x02c7d620, nsIPresContext * 0x0406fef0, nsEvent * 0x0012f32c, nsIDOMEvent * * 0x0012f2f0, unsigned int 1, nsEventStatus * 0x0012f350) line 510 DocumentViewerImpl::LoadComplete(DocumentViewerImpl * const 0x040ae580, unsigned int 0) line 669 + 47 bytes nsWebShell::OnEndDocumentLoad(nsWebShell * const 0x03388ac8, nsIDocumentLoader * 0x03388080, nsIChannel * 0x040c3070, unsigned int 0) line 954 nsDocLoaderImpl::FireOnEndDocumentLoad(nsDocLoaderImpl * 0x03388080, nsIChannel * 0x040c3070, unsigned int 0) line 805 nsDocLoaderImpl::DocLoaderIsEmpty(unsigned int 0) line 612 nsDocLoaderImpl::OnStopRequest(nsDocLoaderImpl * const 0x03388084, nsIChannel * 0x040aef20, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 0x00000000) line 555 nsLoadGroup::RemoveChannel(nsLoadGroup * const 0x03389fc0, nsIChannel * 0x040aef20, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 0x00000000) line 566 + 39 bytes PresShell::RemoveDummyLayoutRequest() line 5337 + 44 bytes PresShell::ReflowCommandRemoved(nsIReflowCommand * 0x040af7a0) line 5290 PresShell::ProcessReflowCommands(int 1) line 5110 ReflowEvent::HandleEvent() line 4995 HandlePLEvent(ReflowEvent * 0x040aaf80) line 5005 PL_HandleEvent(PLEvent * 0x040aaf80) line 576 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00b09d80) line 509 + 9 bytes _md_EventReceiverProc(HWND__ * 0x00
*** Bug 53683 has been marked as a duplicate of this bug. ***
*** Bug 56020 has been marked as a duplicate of this bug. ***
*** Bug 56807 has been marked as a duplicate of this bug. ***
*** Bug 56817 has been marked as a duplicate of this bug. ***
Adding mostfreq keyword based on comments on irc about this. Are we going to try to fix this or not?
Argh!!! Again, I repeat that this is known to be working in build 2000091505. Why should this be so difficult to fix? Anyone trying out ChatZilla for the first time will wonder how the heck they can see all the content because this bug makes it so no scrollbars show up for messages that move out of view of the current viewport. I have a script that grabs all existing links on your web page, opens a new window, and writes to that window. Any browser that supports javascript can dynamically write those links to the window and get scrollbars when the content becomes more than the current viewport can display. How can I evangelize Mozilla when my fellow developers ask me "well, why can't it do this simple thing or that simple thing?". I don't care if you have to delay Netscape 6 for another month or 2. No one is holding Netscape to a release date but Netscape. So, just delay for a bit rather than put out a browser with significant bugs like this one. My god, I saw some crashers that were even minused. I know you have to cut things off at some point, but sheesh. This stuff is very important to a functioning browser! Please reconsider rtm++'ing this and provide reasoning if you are going to leave it munused!!!! Jake
This should obviously go onto the Mozilla0.9 radar.
56882 looks like the same issue.
*** Bug 61983 has been marked as a duplicate of this bug. ***
I need a fix for this one a.s.a.p. Will not wait for two more months! Thats to odd for words. This is a basic function of any kind/brand or type of browser. It's like telling your kids, I have something really nice for you, but hey, you can't eat it! You will have to wait for two months, or are we going for 4? You might say what you want, but at least this is working in IE, and all the rest! Friendly, HJ.
Ok, I would like to add this comment: Try this link: http://members1.chello.nl/~j.c.drost/mozilla/sm62263-4.html For an example to put two scrolbars on a newly opend window. But then you can't use them. My point here is, that the scrollbars are still on the window. I just opened a new window with 'window.open' and put a filename in, with a large image! And take a look at the bottom of your scren, whats' that gray load indicator doing there? Is it still loading or what? I can't do more for now! Friendly, HJ.
*** Bug 58498 has been marked as a duplicate of this bug. ***
Hey Steve, could you look at this one?
nominating for beta1 since multiple-engine search is largely useless because of this (bug 55334)
*** Bug 65440 has been marked as a duplicate of this bug. ***
*** Bug 65485 has been marked as a duplicate of this bug. ***
There is a work-a-round for this serious bug. open a window like this: Win81 = open("scroll-bar.htm","WinSW2","height=200,width=475,scrollbars=1") scroll-bar.htm has this for body: <BODY> <SCRIPT LANGUAGE ="JAVASCRIPT"> opener.doWrite() </SCRIPT> </BODY> the doWrite() function writes whatever you want.
Yes, that works but it's a bit klunky and it doesn't help if you're working with frames or iframes I'm afraid.
*** Bug 66141 has been marked as a duplicate of this bug. ***
*** Bug 66552 has been marked as a duplicate of this bug. ***
*** Bug 68218 has been marked as a duplicate of this bug. ***
Additional Comments From Bill binkley 2001-01-15 01:40 are an "ok" workaround for new content... but most folks i've talked to would rather just leave the old stuff broken and blame it on Netscape rather than re-write the sites. (again) Thanks to bill for the workaround. regards, rich
The presented workaround is only good if a new window has to be opened. If no window needs to be opened (usual case, I presume), it is useless. I just hope it won't miss the mozilla0.9 train! Patrick
So, is anyone working on this anymore? This hasn't worked since the middle of September. I stated the last build where scrollbars worked. evaughan traced the down the reason why it isn't working. Seems like that is half the battle. The workaround doesn't work for everything that I need and why should I do a workaround for a beta browser? That just saps the motivation to fix the problem in the first place. I hope this isn't taken as spam. I just wanted to get a reminder out there to make sure this bug isn't forgotten. Jake
buster's gone. jst, I know you're in the middle of other stuff, but can you fix this in time for 0.9, or find someone who can? /be
*** Bug 65844 has been marked as a duplicate of this bug. ***
Created attachment 27973 [details] [diff] [review] WIP for a hackaround that fixes the problem.
*** Bug 56882 has been marked as a duplicate of this bug. ***
So, is jst's fix one that could be checked in? Like Brendan said, he'd like to have it in by 0.9 just really hoping to have this fixed soon! Jake
Created attachment 30453 [details] [diff] [review] Better fix, r= anyone?
Nit: use --count >= 0 rather than + while (count-- > 0) { to avoid a temporary. Can you cite the bugzilla bug# for the scrollbar bug being worked around? /be
Brendan, this is the bug I'm working around, see evaughan@netscape.com 2000-10-13 13:26. The scrollbar code needs to be able to cope with the root element changing in a document, and currently that involves setting the document in the old root to null. I will leave this bug open after my workaround is checked in. I added a reference to this bug in a comment in nsHTMLDocument.cpp. I also changed while (count-- > 0) to while (--count >= 0).
Ok, workaround checked in, reassigning to evaughan in hope of getting a real fix for this problem in the scrollbar code. Eric, the scrollbar code must be able to function properly even if the root element in a document is removed and re-inserted, or simply just replaced. This can happen in the case where a script writer does document.open()... (see attached testcase) or if someone replaces or removes the root element in a document from script, both cases are valid cases and the scrollbar code simply needs to cope with this. To test this either back out my workaround and run the attached testcase or shout and I'll create a testcase that replaces the root in a document.
Thanks jst!!!! I just tested it with win32 talkback build #2001041204 on Win2k and it works great! Hopefully the root problem can be fixed also, but this is awesome! Thanks again! :-) Jake
jst/evaughan, would you mind if I opened a new bug for the underlying problem and marked this one as fixed? This bug is getting very long, and has mostfreq/nsbeta1+ keywords. I also link to this bug from my website (since it broke a few of my bookmarklets) and don't want visitors to think the "No scrollbars for javascript-generated content" part of this bug hasn't been fixed.
Jesse, feel free to close this bug and open a new one against evaughan, when you do that, please make sure you note the number of the new bug here.
Filed bug 78070 for the underlying scrollbar problem. (jst, please make sure I got most of the details right in that bug.) Marking this bug as fixed for mozilla0.9.
*** Bug 77848 has been marked as a duplicate of this bug. ***
Marking verified in the May 22 build.
or
