If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

RESOLVED INVALID

Status

()

Firefox
General
RESOLVED INVALID
11 years ago
11 years ago

People

(Reporter: Moriyoshi Koizumi, Unassigned)

Tracking

({testcase})

2.0 Branch
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
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>
Created attachment 262747 [details]
testcase from comment#0
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

11 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

11 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

11 years ago
I managed to run it with the environment variable GTK_IM_MODULE being blank and just found the same  persists.

Comment 6

11 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.
What's this bug? The reporter is using mac, but it is crashed in GTK???
(Reporter)

Comment 8

11 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). 
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

11 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

11 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
Last Resolved: 11 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.