Closed Bug 461679 Opened 16 years ago Closed 16 years ago

Browser UI and page rendering engine lock-up if cookie dialog box appears while dragging tab to new position

Categories

(Firefox :: Tabbed Browser, defect)

defect
Not set
major

Tracking

()

VERIFIED DUPLICATE of bug 100180

People

(Reporter: kadams, Unassigned)

Details

(Keywords: hang)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.14) Gecko/20080429 PCLinuxOS/2.0.0.14-1pclos2007 (2007) Firefox/2.0.0.14
Build Identifier: Mozilla Firefox 3.0.3 on Ubuntu Hardy 8.04

In Firefox 2.0.0.x and 3.0.x on Linux (and occasionally in Windows), Gecko (the page rendering engine) and XUL/Chrome (the browser UI) will hard-lock if a cookie dialog box appears while I am dragging a tab to a different position in the tab bar.

Reproducible: Always

Steps to Reproduce:
I can reproduce the bug in this fashion:


 1. In "Privacy" options, set the Cookie options as:

    [x]  Accept cookies from sites

        [ ]  Accept third-party cookies

        Keep until:  [ask me every time]


 2. Close all tabs (to start with a clean slate).


 3. User "Clear Prive Data..." to delete all
    cookies from your browser.  For purposes
    of this discussion, make especially sure
    you have NO cookies set for Twitter.


 4. Open a static, relatively cookie-free page, such as
    Google, in the first tab:

        Tab #1 = http://www.google.com/


 5. Open a "sets a cookie according to a timer" page,
    such as this URL at Twitter:

        Tab #2 = http://search.twitter.com/search?q=3g+iphone+reception


 6. Switch to Tab #1 (the Google tab).


 7. Click/hold on Tab #1 (the Google tab) to initiate
    a tab-dragging operation.  Drag the tab enough so
    the "drop tab here" indicator appears on the other
    side of Tab #2 (the other tab).

    DO NOT release the tab (i.e., do not let off the
    mouse button) until the page in Tab #2 (the other
    tab) requests to set a cookie.


 8. Twitter will want to set a cookie, with
    data similar to this one:

        Confirm setting cookie

        The site search.twitter.com wants to set a cookie.

        [ ]  Use my choice for all cookies from this site

        [Hide Details]  [Allow]  [Allow for Session]  [Deny]

        Name:      _search_twitter_sess
        Content:   [some session string]
        Host:      search.twitter.com
        Path:      /
        Send For:  Any type of connection
        Expires:   at end of session

Actual Results:  
The browser hard-locks:

 1. The cookie dialog box can be neither answered
    nor dismissed.

 2. The tab-dragging operation never completes.

 3. If the foreground tab (the tab being dragged)
    has not yet completed rendering, it never
    completes.

 4. Other tabs (those that are not being dragged)
    may not complete rendering, but this is a
    moot point, because the UI no longer responds
    to user (mouse/keyboard) events, so one cannot
    switch to those tabs to verify progress.


Expected Results:  
Either of the following results would be acceptable:

 1. The display of cookie request dialog boxes
    should be placed on hold until the tab-dragging
    operation is complete.

 2. The display of a cookie request dialog box
    should gracefully interrupt the tab-dragging
    operation and cause the tab to revert to
    its original position in the tab bar.

in conjunction with:

 A. The browser UI should remain responsive to
    user (mouse/keyboard) events.

 B. The page layout engine should resume the
    renderring of pages if renderring was
    interrupted.
Keywords: hang
URL: Various
URL: Various
I think this is a duplicate of Bug 100180.
(In reply to comment #1)
> I think this is a duplicate of Bug 100180.

Agreed.

<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=100180#c54">Comment #54</a> does a good job of explaining the problem I have encountered.

However, my searching (using terms like "cookie tab", "tab cookie dialog", didn't return any results including Bug 100180.  Oh, well...

I will close this bug and go add a vote to Bug 100180.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
V.Duplicate
Severity: critical → minor
Status: RESOLVED → VERIFIED
OS: Linux → All
Hardware: PC → All
Version: unspecified → Trunk
Severity: minor → major
You need to log in before you can comment on or make changes to this bug.