New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Misbehaviors in 3.9.0 :7ad9df044: (8175) #1722
Comments
To help us sort out the issue, can you quit Vienna, put aside its Preferences file ( |
OK... I did this, relaunched, it came up looking good in horizontal view with the bottom (article contents) pane closed. I lifted up the pane divider until it was half and half (which is how I usually use it). Then I selected a newsgroup, and an article line in that newsgroup. Bam, the window immediately readjusted itself to full width and minimum left-hand column, immediately as it displayed the article in the bottom pane. |
Does this happen with every feed or just particular ones? If so, can you post the feed URLs? |
I can't tell if it happens with "every" feed, but it's happened with more than one. I launched it fresh and bopped around a bit... it took me under 30 seconds to make it happen. That particular feed was As to @barijaona 's question, those bugs seem to involve the LH column size changing at launch time. In my case, the LH column is something reasonable at launch time, but slams itself to the minimum size upon choosing some article and then cannot be resized in any fashion short of quitting the app, nor can the window width be reduced to less than the new width, which is slightly more than full screen width (it can be expanded though). It may be significant that I read most of my feeds in "Use Web Page for Articles" mode, and all the misbehavior has occurred so far with one of those feeds. It's exactly as if the app makes a computation when rendering the webpage image that it needs more than the available pane space to display it, and slams the window wide open and the LH column to minimum in an attempt to claim that much space. Just for kicks, after Vienna slammed the window wide open, I tried choosing a different feed that was not in web page mode, to see if the resizing controls would work again, but they didn't. Once they have been set wide, they're stuck until I quit the app. |
I did manage to trigger it now with |
It seems that WKWebView will increase its size to fit the web content (instead of using horizontal scrolling if it does not fit). The WKWebView will expand beyond the size of its split-view area (causing the sidebar to be squished), so much that it even expands the window size (even beyond the display area). |
Sounds good. Don't forget there's a second bug reported here that seems to have dropped through the cracks. |
This one is due to the fact that what the user types is intercepted by Vienna before being sent to the web view. |
Just installed this release onto macOS Monterey 12.7.2.
Upon launch, main window immediately snapped to entire width of screen, and left column snapped to minimum width; neither would respond to any corrective drag attempts, though cursor changed appropriately.
Relaunching seemed to clear this problem up... but shortly after, window snapped into the same state. Furthermore, typing into input fields in posted articles exhibited a further failure -- after typing a single character, input field grayed out and focus was shifted to the search bar. Typing a return character into an input field grayed out the field and opened the article in an external browser.
The text was updated successfully, but these errors were encountered: