Import this URL into a project:
http://www.efilmcritic.com/review.php?movie=19748
When it is rendered:
- It takes an inordinate amount of time to render. Why?
- The URL at the very bottom of the page is looooooong enough that the Scrivener window becomes so wide that it cannot be resized. Once, the window would not resize horizontally at all. Another time the window relocated itself offscreen when I tried to resize it horizontally. Now I can’t get the Scrivener window onscreen.
As far as resizing the main window when the bottom URL (whatever it is) gets longer than the current window size, I’d consider doing so a bug. Is there a way to get the QT HTML renderer, which I expect you’re using (?), to not resize, but to ellipsize the URL instead?
Import this URL into a project:
http://www.ehow.com/list_7486808_swat-sniper-protocols.html
After doing so and trying to look at the imported page, the user has absolutely no control over the window size which is enormous.
This is a bug. The user should have control of the size of the application window(s), not the program.
Help!
I’m afraid I’m unable to recreate the bug.
For the first link you provided, only a blank page is imported. No text. For the second link It imports as expected and the window does not change size.
I do have the convert HTML to text box ticked. You can find this in the general tab of the options menu. To locate options go to Edit > Options.
If you tick this box how successful are your imports?
And that seems to be the critical difference. With “convert to text” enabled, it seems that the web page is not processed by whatever HTML renderer Scrivener is using. The window’s size does not change and stays well behaved.
I think if you want to reproduce my results, you would uncheck “convert to text”. I have tried both states and can only reproduce the problem when “convert to text” is unchecked.
When “convert to text” is not checked, there seem to be two problems with HTML rendering:
- The HTML renderer tries to display some kind of URL at the bottom of the page. On the two examples above, that URL is amazingly long. The HTML renderer increases the size of the window in order to display that URL at the bottom of the window.
- If the size of the HTML page itself is larger than the current size of the window, the window size is changed.
In both of these cases, I would rather have Scrivener add a horizontal scroll bar to the window rather than changing the width of the window itself.
Thanks for trying to reproduce the bug. At least I now have a workaround.
Just repeated test on first URL with convert box unchecked.
Page takes about 1 min to import but my editor window does not resize itself during import.
Just had a thought. What size screen/monitor are you using? My laptops screen doesn’t work so I have a 19 inch external monitor. I was thinking this might be a netbook or small screen issue.
Can anybody with a netbook reproduce this issue?
Another variable would be browser. I am using Firefox 3.6.17.
And I am using a 24" LCD monitor. And yes, the Scrivener window is resized larger than 24".
Hmmm interesting. I am using Firefox 4.0.1. Is it possible for you to do a screenshot of the Scrivener window?
Also what operating system are you using? Vista, Windows 7 etc?
I am using Vista. My comment about the browser being an issue is probably not an issue at all. The browser (or program name) will have been supplied by Scrivener, and since we’re both running that program, the odds that we received different HTML because our requesters were identified differently is probably nonexistent.
The issue might also require a window redraw, that is, the mouse might have to be in the web page being rendered, and the mouse might also have to be moved once, I don’t know. There might be some funky widget redraw behavior going on here.
So, the screenshot is attached. Let me know if you would like anything else. And thanks for investigating the problem.
regards,
-jim
I am going through the project that has these links and converting them to text files. I’ll make a copy of the project before I go any further and make sure I have something to test with if the bug gets fixed.
I can confirm that the mouse does have to be in the document window for the bug to manifest. If I select a URL that would mung the Scrivener window’s width, but I don’t put the mouse pointer into the document window, everything seems well behaved; the window remains at its current width. But if I select the same URL from the binder, wait for it to completely render (which can take quite a while sometimes), and then place the mouse pointer in the document window (and sometimes wait a second or two), the window gets resized.
Seems to be some sort of widget redraw thing.
