GNOME Bugzilla – Bug 324190
yelp window is maximized but contents of window are not
Last modified: 2009-09-22 01:48:06 UTC
This bug has been opened here: http://bugzilla.ubuntu.com/show_bug.cgi?id=21050 "This is a fresh load of Dapper Flight2 with updates. The first time that the window is maximized the window expands but contents of window dont expand to fill window. workaround: Clicking on a topic link fixes the issue. Window gets saved correctly on exit and problem never appears again."
"me too", on Dapper as well.
Does that mean the whole contents of the window (i.e. including the toolbar and menubar), or just the content area with the displayed help file?
Created attachment 56678 [details] "Before"
Created attachment 56679 [details] "After"
> Does that mean the whole contents of the window (i.e. including the toolbar and > menubar), or just the content area with the displayed help file? I attached a couple screenshot to show exactly what happens, once you maximize the window for the first time after launching Yelp. It's 100% repeatable: just make sure yelp isn't maximised, close it, open it again, maximize... and witness the bug.
Hi, I'm seeing this bug too with gecko 1.8 (firefox 1.5). With 1.7 (firefox 1.0), the resizing works as expected. I'm also seeing that it doesn't extend out any of the other widgets i.e. toolbar and side panel stay the same size / position as they were and the window grows a grey border down the right and bottom sides. Just to confuse matters slightly more ;)
So this is a mozilla bug right? chpe?
I'm guessing this is a mozilla bug. I can reproduce it in devhelp as well, so its not just Yelp.
Notice that the failure to resize the window's contents happens on every resize until you click on a topic link. I can resize the window multiple times and the contents don't resize until I click on one of the links.
Ok, a few more notes for any intrepid adventurers attempting to look into this: 1. As Dooglus says, the window can be resized multiple times without the contents following 2. For me at least, clicking anywhere in the content pane will result in the bug fizing itself 3. When you do the above, with a11y enabled, yelp spits out a couple of warnings: (yelp:29666): GLib-GObject-WARNING **: gsignal.c:1028: unable to lookup signal "activate" of unloaded type `MaiAtkObject' (yelp:29666): GLib-GObject-CRITICAL **: g_signal_emit_valist: assertion `signal_id > 0' failed Breaking on g_log functions produces the backtrace: Breakpoint 2, IA__g_log (log_domain=0xb71c17bc "GLib-GObject", log_level=G_LOG_LEVEL_WARNING, format=0xb71c3fd4 "gsignal.c:1028: unable to lookup signal \"%s\" of unloaded type `%s'") at gmessages.c:516 516 va_start (args, format); (gdb) where
+ Trace 65070
Not entirely certain that the warnings are related to the bug itself, but I don't recall seeing them prior to the bug appearing and they only appear once, when the bug manifests itself. After the warnings appear and the window fixes itself, the warnings no longer appear when clicking in the window... Enjoy
The warnings are entirely unrelated to this bug (they should however be filed in a separate yelp bug :). I suspect this is https://bugzilla.mozilla.org/show_bug.cgi?id=312998 .
Created attachment 57801 [details] [review] Proposed fix Hi, I managed to stumble across a possible solution to this, but I'm not entirely certain how it works ;) The problem seems to be related to the uimanager stuff. The patch removes the call to gtk_ui_manager_ensure_update and moves some other stuff out of window_populate. This seems to make the problem go away for me. Note, that this is the minimum moving of stuff that makes the problem go away. This doesn't seem to introduce any new problems for me, but can someone test this, see if it causes any problems for anyone else? Cheers
doesn't seem to cause any regressions against ff 1.0.7 (gecko 1.7?) at first glance
*** Bug 326803 has been marked as a duplicate of this bug. ***
Don: can you file the traces from comment 10 in a separate bug? They're unrelated to this. About the patch: I'm suspecting that it somehow causes the initial focus (i.e. focus when the window is shown) to be on the YelpHtml widget. You could try doing that directly, and see if it has the same effect?
Hi, I've just committed a (1 line) fix for this. The fix is to set the initial focus to the html widget. Christian: I didn't file a seperate bug as it is related to this. I can't reproduce the problem I described when this bug is fixed. Closing 2006-01-23 Don Scorgie <dscorgie@cvs.gnome.org> * src/yelp-window.c: Set initial focus to html widget, fixes #324190