Closed
Bug 378717
Opened 18 years ago
Closed 18 years ago
Creation of frames with the special names causes hang-up.
Categories
(Firefox :: General, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: moriyoshi, Unassigned)
Details
(Keywords: testcase)
Attachments
(1 file)
|
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>
|
||
Comment 1•18 years ago
|
||
|
|
||
Comment 2•18 years ago
|
||
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
|
||
Comment 3•18 years ago
|
||
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/
|
Reporter | |
Comment 4•18 years ago
|
||
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 ?? ()
|
|
Reporter | |
Comment 5•18 years ago
|
||
I managed to run it with the environment variable GTK_IM_MODULE being blank and just found the same persists.
|
|
||
Comment 6•18 years ago
|
||
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.
|
||
Comment 7•18 years ago
|
||
What's this bug? The reporter is using mac, but it is crashed in GTK???
|
|
Reporter | |
Comment 8•18 years ago
|
||
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).
|
|
||
Comment 9•18 years ago
|
||
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.
|
|
Reporter | |
Comment 10•18 years ago
|
||
> 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...
|
|
Reporter | |
Comment 11•18 years ago
|
||
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: 18 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•