554818 - Search bar does not remember its width

Status: RESOLVED INCOMPLETE

(Camino Graveyard :: Toolbars & Menus, defect)

Description

[Paul Borokhov (lensovet)]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en; rv:1.9.0.18) Gecko/2010021619 Camino/2.0.2 (like Firefox/3.0.18)
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en; rv:1.9.0.18) Gecko/2010021619 Camino/2.0.2 (like Firefox/3.0.18)

When Camino quits unexpectedly, the width of the search box is not remembered and instead resets to the default.

Reproducible: Always

Steps to Reproduce:
1. Resize search bar to be wider than normal
2. Force Quit Camino
Actual Results:  
Open Camino. Observe search bar width has been forgotten

Expected Results:  
Search bar width should have been remembered

Comment 1

[philippe (part-time)]

It doesn't reset to the default but to the size that was saved in the previous session.

( I made the search bar extra large, quit to save that size, started Camino, resized the search bar to something smaller, force quit. Next session used the extra large search bar).

This behaviour has been the same for the whole of 2009.

Comment 2

[Stuart Morgan]

The width is saved via NSUserDefaults, which synchronizes to disk periodically. If you force quit before that happens, the change will be lost. That's a basic behavior of NSUserDefaults, and thus common to most applications on the Mac.

We're not going to force a synchronous prefs write the moment someone adjusts the search bar or the off-chance that Camino might crash immediately after.

Comment 3

[Paul Borokhov (lensovet)]

sorry but it *never* saves. i resize the bar immediately after starting camino; then my machine becomes inoperable due to something like coreserviced crashing a week later; after restarting i have to resize again.

given that resizing doesn't happen very often, i don't see the harm in calling |synchronize| after the bar is resized.

Comment 4

[Paul Borokhov (lensovet)]

furthermore looking at the code i see this:
In BrowserWindowController windowDidLoad, setAutosaveSplitterPosition is called with NO
In ExtendedSplitView saveSplitterPosition, nothing happens since setAutosaveSplitterPosition is NO
Search bar width is saved in one place only, BrowserWindowController autosaveWindowFrame, which is only called when
(1) window is closed
(2) new window is about to be created
(3) Camino quits
This has nothing to do with synchronizing NSUserDefaults and everything to do with never calling setFloat after a resize operation.

Comment 5

[Chris Lawson (gone)]

(In reply to comment #4)

> This has nothing to do with synchronizing NSUserDefaults and everything to do
> with never calling setFloat after a resize operation.

Did anyone else ever take a look to see if this was, in fact, true?

And if it is, why does it work fine for some people and not the reporter?

Comment 6

[Paul Borokhov (lensovet)]

> And if it is, why does it work fine for some people and not the reporter?

It works "fine" if you properly close/quit Camino. It doesn't work if Camino quits unexpectedly either due to a crash or a system hang. The misconception in comment 2 is that it should save *at some point* on its own (i.e. without a quit/close event), but the reality is that it doesn't.

My question from comment 4 still stands: why is setAutosaveSplitterPosition set to NO? Once we have an answer to that, a one-line patch is all it will take to fix this bug.

Comment 7

[Stuart Morgan]

(In reply to comment #6)
> My question from comment 4 still stands: why is setAutosaveSplitterPosition set
> to NO?

Because the autosave code won't interact correctly with the collapsing code, or the window sizing code given that it's a flexible element in the window.

> Once we have an answer to that, a one-line patch is all it will take to
> fix this bug.

This presupposes that the answer to your first question is "because we don't know what we're doing" and that the fix is therefore to remove the line.

We could make ExtendedSplitView autosaving smart about collapsed subviews (although not in one line), but I don't see how to get sensible interaction with window size mismatches unless we add a bunch of complexity to ESV to handle a flex-box-like specification of how resizing should work.

Given that it's interactive with window resizing, saving with window frame seems perfectly reasonable to me, so I'm inclined to WONTFIX this. If someone really wants to go to the effort to make a well-designed change to ESV just to handle this edge case I guess I'd be okay with that though, so let's call it Future.

Comment 8

[Paul Borokhov (lensovet)]

> Given that it's interactive with window resizing, saving with window frame
> seems perfectly reasonable to me, so I'm inclined to WONTFIX this. If 
> someone
> really wants to go to the effort to make a well-designed change to 
> ESV just to
> handle this edge case I guess I'd be okay with that though, so let's call it
> Future.
Wait, but then this implies that the window frame only saves on window close/quit as well, which also seems wrong. Shouldn't the window frame save…whenever I change the window frame?