Opened 4 years ago

Closed 4 years ago

#224 closed bug (fixed)

Behaviour of the detached Tabs

Reported by: Samir Hawamdeh Owned by: Thore Böckelmann
Priority: normal Milestone: 4.0-2015R3
Component: Window.mui Version: 4.0-nightly build
Severity: minor Keywords:
Cc: OS Platform: AmigaOS4
Blocked By: Blocking:
Release Notes:

After opening a window a notification of the MUIA_Window_Activate attribute is triggered. This is required by Odyssey to let it correctly keep track of the last active window.

Description

Summary

In Odyssey Web Browser and possibile in any other similar programs you can remove one of the tab by simply dragging one of the opened tab outside the main window (this will open this tab in a new browser window)

In short this functionality will open a new fresh window with the contents of the tab you have detached, ok

At this point, however, if you try to open a new tab by playing inside this second browser window, any new tab will be opened inside the first window rathen then into the second one !

This particular behavior can provoke a very strange side effects, for example what happen if you just close the first window of OWB but you still want browsing the web using this secondian window ?

It happen that now you will be prevented from opening any other new tabs, this because the system expects to find atleast the main window (the parent one) in which opens all those new tabs

I don't have a solution, maybe an extra check to verify if the first (parent) window is open and in case open all these new tab into it, otherwise choose automatically the second one etc …

Or maybe just change the whole behaviour in order to open any new tab ONLY within the window you are playing on (maybe the logical solution at this point)

Don't know, for sure the current behaviour can result in a bug

Steps to reproduce

  1. Open Odyssey Web Browser
  2. Open two different tabs
  3. Drag one of the tabs outside the main window in order to open a fresh window
  4. Now close the first window and try to open new tabs in this secondatian window

Expected results

New tabs should be opened in this secondarian window

Actual results

Tabs can't be opened and nothing happen if you try to open them !

Change History (12)

comment:1 Changed 4 years ago by Thore Böckelmann

Component: List.muiTitle.mui

comment:2 Changed 4 years ago by Thore Böckelmann

Owner: set to Thore Böckelmann
Priority: undecidednormal
Status: newassigned

I finally managed to try this myself. But for me everything is working as expected. Dragging a tab outside its window moves it to a new window and any "new tab" actions in that second window correctly open new tabs in the second window, as well as any "new tab" actions in the original first window open the new tabs there.

However, what is not working are D&D operations of tabs between the two windows. This is still causing a crash due to a NULL pointer. I am currently working on this.

comment:3 Changed 4 years ago by Thore Böckelmann

In 4819:

  • Title.c: fixed a possible NULL pointer access when dragging a tab between different objects. The dropmark object must be created during OM_NEW instead of just when the D&D action starts. This refs #224.

comment:4 Changed 4 years ago by Thore Böckelmann

Have you tried to reproduce this issue recently? Unfortunately I am currently lacking the time to check myself.

comment:5 Changed 4 years ago by Thore Böckelmann

I managed to reproduce this issue myself yesterday. Choosing "Open in new tab" from a quicklink button's context menu triggers the misbehaviour for me. Although I am not 100% if this might be a bug in Odyssey's own active window handling.

According to the public source of 1.23 the "Open in new tab" item tells OWB to open a new tab in the last active window. It seems this logic is screwed up when there is no explicit "set(win, MUIA_Window_Activate, TRUE)" after opening the window. By default windows are opened in active state, but no notification for the attribute MUIA_Window_Activate is triggered. I will add this.

comment:6 Changed 4 years ago by Thore Böckelmann

Component: Title.muiWindow.mui

comment:7 Changed 4 years ago by Thore Böckelmann

In 4833:

  • Window.c: trigger an initial notification for the window's active state right after opening it. this is required by Odyssey to correctly track the last active window. This closes #224.

comment:8 Changed 4 years ago by Thore Böckelmann

Release Notes: modified (diff)
Resolution: fixed
Status: assignedclosed

comment:9 Changed 4 years ago by Samir Hawamdeh

@Thore

Sorry i was busy .. good that you found and fix it, track this bug was a bit complicated .. great that you also found (and fix) another related issue with the D&D operations in tabs … 2 fixed bugs in once :-)

I wait for the next nightly then !

comment:10 Changed 4 years ago by Samir Hawamdeh

Mmm Thore maybe you broke somethings during the process … in Odyssey (since r4834) i can't be able to move any tab from a position to another (inside the same window) ..

If i hold my mouse over them and i try to move things the "drag effect" is visible but when i release the mouse button the tab will NOT be dragged, however it seems I can drag tabs from a window to another with no problem (but i can't drag things inside the same window) …

comment:11 in reply to:  10 Changed 4 years ago by Thore Böckelmann

Resolution: fixed
Status: closedreopened

Replying to samo79:

Mmm Thore maybe you broke somethings during the process … in Odyssey (since r4834) i can't be able to move any tab from a position to another (inside the same window) ..

You are right. The changed handling of the MUIM_DragFinish method invalidates the drop position, which is definitely wrong.

comment:12 Changed 4 years ago by Thore Böckelmann

Resolution: fixed
Status: reopenedclosed

In 4843:

  • Title.c: don't invalidate the drop position during MUIM_DragFinish. This closes #224 again. Also redraw the object only once in case the drop happens within the same object.
Note: See TracTickets for help on using tickets.