Closed Bug 378717 Opened 17 years ago Closed 17 years ago

Creation of frames with the special names causes hang-up.

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Version:
2.0 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: moriyoshi, Unassigned)

Details

(Keywords: testcase)

Attachments

(1 file)

testcase from comment#0
104 bytes, text/html
Details 
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/419 (KHTML, like Gecko) Safari/419.3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; ja; rv:1.8.1.3) Gecko/20060601 Firefox/2.0.0.3 (Ubuntu-edgy)

I'm not sure since when the bug has occurred, a plain HTML document that includes iframes or a frameset appears to make FireFox to not respond to any operations.

Reproducible: Always

Steps to Reproduce:
1. Create the following HTML document
<html>
<frameset cols="*">
<frame src="http://www.hatena.ne.jp" name="parent" />
</frameset>
</html>

2. Let the browser read it by either [Open File...] or whatever.

Actual Results:  
The browser hangs up.

Expected Results:  
Nothing wrong should happen. The frame should be treated as if no name was specified.

The following ends up in pretty much the same state.

<html>
<body>
<iframe name="parent">
</iframe>
</body>
</html>
testcase works for me on Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.4pre) Gecko/2007042403 BonEcho/2.0.0.4pre - no hang, took a few seconds till the frame site http://www.hatena.ne.jp/ was loaded but no hang and target site is displayed correctly
Component: Help Documentation → General
Keywords: testcase
QA Contact: help.documentation → general
Version: unspecified → 2.0 Branch
Works for me, Firefox 2.0.0.3 en-US (mozilla.com build) on Linux (Ubuntu edgy)

Moriyoshi-san, does the crash also occur in the official mozilla.com build?
http://www.mozilla.com/
I forgot to mention that I first experienced the problem on Mac OS X with the build of the following identifier:

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; ja-JP-mac; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

The official build isn't launched in my environment and immediately runs into segfault for unknown reasons. The same occurs for the nightly build I grabbed from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2007-04-25-04-mozilla1.8/ .

Although I doubt the relevance of this with the main issue, here's the backtrace I generated with the following configuration:

Build used:
Mozilla Firefox 2.0.0.4pre, Copyright (c) 1998 - 2007 mozilla.org
% ./firefox -g -d gdb

#0  0xb73c2a2e in free () from /lib/tls/i686/cmov/libc.so.6
#1  0xb5da7fc1 in operator delete () from /usr/lib/libstdc++.so.6
#2  0xb5d84d3d in std::string::_Rep::_M_destroy () from /usr/lib/libstdc++.so.6
#3  0xb5d878c7 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string () from /usr/lib/libstdc++.so.6
#4  0xb5e26d6b in scim::FrontEndModule::FrontEndModule ()
   from /usr/lib/libscim-1.0.so.8
#5  0xb5e28d05 in scim::scim_global_config_read ()
   from /usr/lib/libscim-1.0.so.8
#6  0xb5e56d16 in scim::scim_get_default_socket_timeout ()
   from /usr/lib/libscim-1.0.so.8
#7  0xb5e54bc4 in scim::PanelClient::PanelClientImpl::PanelClientImpl ()
   from /usr/lib/libscim-1.0.so.8
#8  0xb5e53420 in scim::PanelClient::PanelClient ()
   from /usr/lib/libscim-1.0.so.8
#9  0xb5ec5121 in ?? () from /usr/lib/gtk-2.0/2.10.0/immodules/im-scim.so
#10 0xb5ed6536 in im_module_init ()
   from /usr/lib/gtk-2.0/2.10.0/immodules/im-scim.so
#11 0xb5ec3285 in _init () from /usr/lib/gtk-2.0/2.10.0/immodules/im-scim.so
#12 0xb7f2ee63 in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
#13 0xb7f2ef73 in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
#14 0xb7f32ac4 in _dl_make_stack_executable () from /lib/ld-linux.so.2
#15 0xb7f2ea96 in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
#16 0xb7f323c9 in _dl_make_stack_executable () from /lib/ld-linux.so.2
#17 0xb7d7be1d in dlopen () from /lib/tls/i686/cmov/libdl.so.2
#18 0xb7f2ea96 in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
#19 0xb7d7c49c in dlerror () from /lib/tls/i686/cmov/libdl.so.2
#20 0xb7d7bd54 in dlopen () from /lib/tls/i686/cmov/libdl.so.2
#21 0xb78ed609 in g_module_open () from /usr/lib/libgmodule-2.0.so.0
#22 0xb7b46ae9 in gtk_im_context_simple_new ()
   from /usr/lib/libgtk-x11-2.0.so.0
#23 0xb791ab18 in g_type_module_use () from /usr/lib/libgobject-2.0.so.0
#24 0xb7b4738e in _gtk_im_module_create () from /usr/lib/libgtk-x11-2.0.so.0
#25 0xb7b47f9b in gtk_im_multicontext_new () from /usr/lib/libgtk-x11-2.0.so.0
#26 0xb7b48199 in gtk_im_multicontext_new () from /usr/lib/libgtk-x11-2.0.so.0
#27 0xb7b455ce in gtk_im_context_set_client_window ()
   from /usr/lib/libgtk-x11-2.0.so.0
#28 0x0824b7d3 in XmlInitUnknownEncodingNS ()
#29 0x08248a9e in XmlInitUnknownEncodingNS ()
#30 0x08244d6a in XmlInitUnknownEncodingNS ()
#31 0x0864cb37 in nsXPTCVariant::Init ()
#32 0x0864c175 in nsXPTCVariant::Init ()
#33 0x0864bf47 in nsXPTCVariant::Init ()
#34 0x086a700e in nsXPTCVariant::Init ()
#35 0x0807ccf0 in ?? ()
#36 0x08b39d40 in ?? ()
#37 0x00000000 in ?? ()


I managed to run it with the environment variable GTK_IM_MODULE being blank and just found the same  persists.
Hmm, judging by the stack in comment 4 it doesn't look like any of our code
is responsible for the crash.  It looks like a GTK or libscim bug.
What's this bug? The reporter is using mac, but it is crashed in GTK???
Please don't be fooled by the backtrace :) As mentioned, the SCIM issue is probably  another one because I experienced the same problem both on Mac and Linux (Ubuntu). 
Please don't comment *another* issue. It should be separated to another bug if it is an "our" bug.

We need more details of your environment.
# And I hope that you come to bugizlla-jp.
> Please don't comment *another* issue. It should be separated to another bug if
it is an "our" bug.

So I said that I was not sure if the crash is anyway related to the main issue though I hoped the information would be a help. Did you read the comments through?

BTW, I reproduced the problem with the following user agent.

  Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

I don't know why you guys haven't ever reproduced this...


My bad. It eventually turned out that the issue was caused by the FireBug add-on. With the add-on off the testcase passed perfectly.

I re-filed this as a FireBug bug to be issue #164.
http://code.google.com/p/fbug/issues/detail?id=164

Thanks for all your help and inputs.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: