Opened 6 years ago

Closed 2 years ago

#10032 closed bug (fixed)

StyledEdit "Save As..." window does not open under certain circustances.

Reported by: bga Owned by: nobody
Priority: normal Milestone: R1
Component: Kits/libtracker.so Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

I guess I saw it happen in more than 0ne case, but this is one way i can reproduce it 100% of the time.

1 - Open StyledEdit. 2 - Write something. 3 - Mount any partition other than the boot one (does not even need to be a writtable one). 4 - Select "Save As..." and try to save to any path inside this newly mounted partition. 5 - Now unmount the partition. 6 - Try to "Save As..." again.

Expected behavior:

"Save As..." window opens.

Observed behavior:

"Save As..." window did not open.

Attachments (1)

0001-stylededit-save-as.patch (1.3 KB ) - added by Freeman 6 years ago.

Download all attachments as: .zip

Change History (14)

comment:1 by siarzhuk, 6 years ago

Owner: changed from korli to siarzhuk
Status: newassigned

Published as GCI 2013 task.

comment:2 by anevilyak, 6 years ago

Component: Applications/StyledEditKits/libtracker.so

From a quick look at this ticket, this may not be the wisest thing to issue a GCI task for.

The actual problem lies down in BFilePanel itself, at least with the above steps to reproduce: A normal Tracker window will close itself when the folder it's displaying goes away. Meanwhile, StyledEdit keeps its file panel around and reuses it in order to remember the last location the user browsed to.

In the above instance, upon volume unmount, the hidden window notices that via node monitor, and dutifully quits itself, so when StyledEdit asks the panel to re-show itself again in response to Save As, it silently fails due to failing to lock its (no longer valid) child window.

Fixing this will possibly mean some Tracker refactoring, as I'm not sure if the appropriate hooks are present for the aforementioned behavior to be overridden by a BPoseVIew/ContainerWindow child class.

in reply to:  2 ; comment:3 by siarzhuk, 6 years ago

Replying to anevilyak:

The actual problem lies down in BFilePanel itself, at least with the above steps to reproduce: A normal Tracker window will close itself when the folder it's displaying goes away. Meanwhile, StyledEdit keeps its file panel around and reuses it in order to remember the last location the user browsed to.

IMO it is not the problem of API if some credulous program uses imprudently some _pointed_ resource that it not owns completely. Even if this API was designed untidy. ;-)

In other words I see here just issue of using this object in some unusual way - so some additional awareness should be introduced in SE.

In the above instance, upon volume unmount, the hidden window notices that via node monitor, and dutifully quits itself, so when StyledEdit asks the panel to re-show itself again in response to Save As, it silently fails due to failing to lock its (no longer valid) child window.

Thanks for investigations. There are something to say about - but I have to keep silence until the end of GCI. This "fruit" is hanging too close after your have explained the source of problem. ;-)

in reply to:  3 ; comment:4 by anevilyak, 6 years ago

Replying to siarzhuk:

IMO it is not the problem of API if some credulous program uses imprudently some _pointed_ resource that it not owns completely. Even if this API was designed untidy. ;-)

In other words I see here just issue of using this object in some unusual way - so some additional awareness should be introduced in SE.

Be themselves recommended using file panels in precisely this way back on the BeCodeTalk mailing list when people asked about having panels remember their last location, so this wasn't exactly something undocumented. Furthermore, the docs specifically indicate that the panel is only supposed to hide itself after the user is done browsing, not destroy entirely, so no, this isn't any unusual use based on the class specs.

Thanks for investigations. There are something to say about - but I have to keep silence until the end of GCI. This "fruit" is hanging too close after your have explained the source of problem. ;-)

The only reason I did so was because the student asked for some help, as his attempts to debug the issue were resulting in a double fault panic in virtualbox every time, the cause of which currently isn't known. In any case, fixing the underlying libtracker issue isn't what I'd call low hanging fruit without some knowledge of Tracker internals, which I doubt the GCI students have.

in reply to:  4 ; comment:5 by siarzhuk, 6 years ago

Replying to anevilyak:

Replying to siarzhuk:

Thanks for investigations. There are something to say about - but I have to keep silence until the end of GCI. This "fruit" is hanging too close after your have explained the source of problem. ;-)

The only reason I did so was because the student asked for some help, as his attempts to debug the issue were resulting in a double fault panic in virtualbox every time,

the cause of which currently isn't known. In any case, fixing the underlying libtracker issue isn't what I'd call low hanging fruit without some knowledge of Tracker internals, which I doubt the GCI students have.

I tend to not underestimating them. Beginners usually have no "blinders" on theirs eyes. I suspect, I'm not the only person that asking "Why the routine that [can] fails do not return any [un]success code?" ;-)

in reply to:  5 comment:6 by anevilyak, 6 years ago

Replying to siarzhuk:

I tend to not underestimating them. Beginners usually have no "blinders" on theirs eyes. I suspect, I'm not the only person that asking "Why the routine that [can] fails do not return any [un]success code?" ;-)

You won't find me disagreeing there :-) Unfortunately changing that particular case would result in ABI compatibility breakage, as BFilePanel::Show() is public.

by Freeman, 6 years ago

comment:7 by Freeman, 6 years ago

Has a Patch: set

comment:8 by diver, 5 years ago

Version: R1/Package ManagementR1/Development

comment:9 by scottmc, 5 years ago

Can someone check over this patch and either apply or it reply here with more info?

comment:10 by pulkomandy, 5 years ago

It only works around the problem explained above. We should instead fix BFilePanel so it doesn't delete itself as mentionned in the ticket.

comment:11 by pulkomandy, 5 years ago

Has a Patch: unset

comment:12 by siarzhuk, 4 years ago

Owner: changed from siarzhuk to nobody

Those were taken some years ago as potential GCI tasks. Unfortunately no place is available for them in my schedule at this days.

comment:13 by KapiX, 2 years ago

Resolution: fixed
Status: assignedclosed

Fixed. (Probably by hrev51502.)

Note: See TracTickets for help on using tickets.