Closed Bug 55334 Opened 24 years ago Closed 23 years ago

No scrollbars for javascript-generated content

Categories

(Core :: Layout, defect, P2)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9

People

(Reporter: conorlennon, Assigned: eric)

References

Details

Attachments

(3 files)

Testcase containing 50 lines of text to demonstrate bug
478 bytes, text/html
Details
WIP for a hackaround that fixes the problem.
8.20 KB, patch
Details | Diff | Splinter Review
Better fix, r= anyone?
4.12 KB, patch
Details | Diff | Splinter Review 
On a page that is generated by javascript, scrollbars do not appear when necessary.
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
Assignee: clayton → jst
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.
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: P3 → P2
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. "
Assignee: jst → evaughan
Keywords: rtm
*** 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?
Whiteboard: [rtm need info]
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
Assignee: evaughan → waterson
*** 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?
Keywords: mostfreq
Whiteboard: [rtm need info] → [rtm-]
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.
Keywords: mozilla0.9
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.
Summary: No scollbars for javascript generated content → No scrollbars for javascript generated content
*** Bug 58498 has been marked as a duplicate of this bug. ***
Hey Steve, could you look at this one?
Assignee: waterson → buster
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9
Blocks: 56882
nominating for beta1 since multiple-engine search is largely useless because of 
this (bug 55334)
Keywords: rtm → nsbeta1
OS: Windows NT → All
Hardware: PC → All
Summary: No scrollbars for javascript generated content → No scrollbars for javascript-generated content
Whiteboard: [rtm-]
*** 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
Assignee: buster → jst
Status: ASSIGNED → NEW
*** Bug 65844 has been marked as a duplicate of this bug. ***
*** 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
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.
Assignee: jst → evaughan
Target Milestone: mozilla0.9 → ---
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.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla0.9
*** Bug 77848 has been marked as a duplicate of this bug. ***
Marking verified in the May 22 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: