Closed Bug 350331 Opened 18 years ago Closed 16 years ago

Pages sometimes fail to render (blank content) when loaded; resizing the window fixes display

Categories

(Camino Graveyard :: General, defect)

Product:
Camino Graveyard
Component:
General
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: peeja, Unassigned)

References

Details

(Keywords: helpwanted, regression, relnote)

Attachments

(1 file)

Backout bug 345425, for testing only
4.55 KB, patch
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1b2) Gecko/20060826 Camino/1.0+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1b2) Gecko/20060826 Camino/1.0+

Occasionally, a page will not display after it (apparently, by the chrome behavior) has loaded, leaving the previous contents of the view in place.  Resizing the window displays the page normally.  Often, refreshing will load the page, but not always.  Sometimes a tab/window (I only browse with tabs) is particularly stubborn and refreshing repeatedly does nothing.  Opening the URL of the problematic tab in a new tab is usually successful.

I see this problem on Facebook more than anywhere else, and one it begins there it usually continues for a while across windows, possibly for the lifetime of the browser session.  When the problem occurs with Facebook pages, however, non-Facebook URLs seem no more affected than usual.

Clicking links on the previous page (the page still erroneously displayed) works, at least the link that led to the not-properly-displayed page.  Clicking that link (a second time) often clears the problem, at least on Facebook.

This is an ugly bug.  I wish it weren't, but it is.  Let's collect our experiences and see if we can make anything out of it.

Reproducible: Sometimes

Steps to Reproduce:
1. Load a URL, from the address bar or by clicking a link.  Bookmarks presumably work as well.



More experiences with this bug are described in the forum at <http://forums.mozillazine.org/viewtopic.php?t=431451>.
The forum topic describes what appear to be several different issues, though they may in fact end up being the same.

I see this randomly, but most frequently in Bugzilla, sometimes in the forum, and on random other pages, and "often" with stand-alone images.  Reloading never has fixed it for me, but once I heard the resize trick, that seems to have worked 100% of the time.  1.8branch builds and 10.3.9 for me.

I feel like confirming this since it's been pretty common lately, but I'd really rather have more of a clue of what's going on, I think, and why forcing reflow seems to fix things.
Flags: camino1.1?
Summary: Pages sometimes fail to display when loaded; resizing fixes → Pages sometimes fail to display when loaded; resizing the window fixes display
I've never once seen this in 1.0.x, so marking as a regression.

cl
Keywords: regression
I just had 3 times in a row.
Steps: 
* a page on my local dev server that is just a list of links (generated via php)
* use FAYT to access a link: type name of link, hit return, Camino should follow link.
* link not followed, but URL says page is loaded
* resize window --> OK

While doing this, I noticed that the found search string did not highlight with green background (FAYT highlight).
Instead, the background-colour for 'selection' -- OS level -- is used.

I've had it (once) recently with a bookmark as well (from a folder in the BM bar)

I've seen the same problem with a 'Cairo-Cocoa' Minefield build, but not (yet) with a CocoaFox (possibly this is the same problem, but Cairo-Cocoa builds are way to buggy on their own to be sure).
Anyone have any ideas on where we should start looking about this, or people to cc?

I haven't seen the "html page" version much recently, but the "image" version of the bug is fairly consistent for images of a certain dimension or KB-size (e.g., any of the mockups at http://www.adggda.com/~ss/camino/mockups/ ).
Severity: normal → major
Target Milestone: --- → Camino1.1
I've been testing the 1.0.3 RCs since RC3 came out, and I don't think I've seen it in that time.  That's nothing conclusive, but it might be a hint.
this is exactly the bug i was talking about the other day on irc where if i dragged an image from the finder into a window, it would load, then dragging a second one wouldn't display. resizing the window would fix it.

this should block, and shouldn't be too hard to walk backwards and find it. it's been w/in the past few months, after spellcheck landed. I had a build pretty close to when spellcheck landed that i was using for a while and I don't think i recall seeing it, but as soon as i updated to a more recent version (build from last week), I noticed it.
Flags: camino1.1? → camino1.1+
Status: UNCONFIRMED → NEW
Ever confirmed: true
I hope this helps...

Procedure:
1) Downloaded Camino branch (1.1) builds from: http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/
2) Mounted the DMG
3) Opened Camino (from the DMG)
4) Drag and drop an JPEG file from my Desktop to the empty window
5) If Camino failed to display the JPEG file, it was considered a bad build

First (oldest) build found to be bad: 2006-07-26-00-1.1-M1.8 (2006072600)
Both builds from 2006-07-24 were fine, and there was no build on 2006-07-25.
(In reply to comment #7)
> First (oldest) build found to be bad: 2006-07-26-00-1.1-M1.8 (2006072600)
> Both builds from 2006-07-24 were fine, and there was no build on 2006-07-25.

Branch regression range: http://tinyurl.com/rg965

Nothing there jumps out at me; it could conceivably be one of the security/js bugs (or possibly the drag/drop change, but that wouldn't/shouldn't explain the "regular pages fail to load" manifestation of the bug)....
Well, both branch and trunk ranges have bug 345425 (and that's the only common bug), so that seems a possible culprit for at least the dragging-image version (maybe the comment 0 flavor is different)?
Flags: blocking1.8.1?
Not blocking 1.8.1 for this, but if you find out that it's something which we do in the branch itself, please nominate for 1.8.1.1 ...
Flags: blocking1.8.1? → blocking1.8.1-
Backing out the patch from bug 345425 fixes this bug in my current trunk build (at least the STR in comment 7, which is the only way I've ever seen this).
Assignee: nobody → mark
(In reply to comment #12)
> Backing out the patch from bug 345425 fixes this bug in my current trunk build
> (at least the STR in comment 7, which is the only way I've ever seen this).

Since I can't back out patches that don't back themselves out cleanly ;) I can't test the other scenarios (which I see a lot, at least the image-as-page not loading flavor), but were someone to post a not-for-checkin backout patch, I'd be more than happy to give it a spin ;)

> were someone to post a not-for-checkin backout patch,
> I'd be more than happy to give it a spin
For a long time I wasn't able to repro the "pages fail to display" bug with the backout patch (thanks torben!) in my trunk build, but I just reproduced it :(

So we're dealing with two different bugs, one in comment 0 - comment 5 (with no solution, and hard to repro) and one in comment 6 and beyond (which is fixed by backing out bug 345425).  Both are regressions.
While testing the drag-and-drop patches from bug 332913 using a Minefield build I noticed the following in both Minefield and Camino-trunk:

.html files - dragging from the Finder (Desktop or folder on the HD)
a. files containing only text: no problems
b. files containing text and an embedded image (using the <img /> element):
blank page, resizing the window fixes the problem.
c. files containing text and a background image: no problems.
(See bug 332913 comment #31)

That Minefield build was also affected by the problems with images in comment #6 and beyond. Nobody noticed this on Minefield because drag-and-drop is broken in non patched Cocoa Minefield builds. 
we should move this over to core then, as it's not camino-specific.
Whatever we do, we need to have a bug for comment 0-comment 5, which is different from the file-dragging issues in comment 6 and beyond.
Tweaking summary to make this a little easier to find.
Summary: Pages sometimes fail to display when loaded; resizing the window fixes display → Pages sometimes fail to render (blank content) when loaded; resizing the window fixes display
I'm not sure this is exactly the same bug, but similar enough I thought I'd just add a comment to this bug number... Sometimes when logging into a website (2 examples are www.realtor.com and www.dreamhost.com), nothing but a blank page appears.  In both cases, the websites are redirecting to another page.  I duplicated the bug in both Camino 1.0.2 and 1.0.3.  These pages load fine in Safari 2.0.4 and Firefox 1.0.6.

Here is some additional environment info:

  Machine Name:       PowerBook G4 15"
  Machine Model:      PowerBook5,6
  CPU Type:           PowerPC G4  (1.2)
  Number Of CPUs:     1
  CPU Speed:          1.5 GHz
  L2 Cache (per CPU): 512 KB
  Memory:             1.5 GB
  Bus Speed:          167 MHz
  Boot ROM Version:   4.9.1f3
  System Version:     Mac OS X 10.4.8 (8L127)
  Kernel Version:     Darwin 8.8.0

I've got a variant of the persistent version of this with the 2/3 branch. Some observations:
- My home page never renders without a resize, but I'm not having trouble with most (any?) other pages
- Force reload and empty cache don't change anything
- View source shows the correct source
- I can't get a context menu for either the page that was there or should be there
- I can partially interact with the page that was there. Loading it over google.com:
  - I can select text
  - I can't drag the logo
  - I get mouseover effects, both cursor and status bar updates
  - I can click links
  - I can can't press the buttons or focus the text field

I'll try attaching with a debugger and poking around, but so far I've crashed every time I tried that before.
Comment 6 through comment 14 have been spun off into bug 370721.  That bug's mento's regression; this one's not necessarily his, so resetting to default.
Assignee: mark → nobody
I can consistently reproduce this by visiting a new image, e.g. http://images.amazon.com/images/P/0312421273.01.MZZZZZZZ.jpg?2 (increment the digit at the end, since it doesn't happen when the image is in the cache). Also, pages with large images in them seem to have the same problem.
#24 this is very recent, much more like ten days than longer.
I check this most days, and never had this problem, consistently at least.

http://www.peepo.co.uk/index.svg consistently white for me, others with slightly older builds have no problem.

I recently rewrote the site and had no problems around 2 weeks ago.
this is SVG so just possibly a separate issue.
Not going to block on this, but it's been relnoted (pink's plus was really for bug 370721, anyway).

Anecdotally, I haven't seen this on the branch since bug 370721 landed (which is consistent with what I saw before in comment 15).
Flags: camino1.5.1?
Flags: camino1.5-
Flags: camino1.5+
Target Milestone: Camino1.5 → Camino1.6
I'm seeing exactly this on Firefox 2.0.0.3 [[Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20061201 Firefox/2.0.0.3 (Ubuntu-feisty)]].

"Occasionally, a page will not display after it (apparently, by the chrome
behavior) has loaded, leaving the previous contents of the view in place. 
Resizing the window displays the page normally.  Often, refreshing will load
the page, but not always.  Sometimes a tab/window (I only browse with tabs) is
particularly stubborn and refreshing repeatedly does nothing.  Opening the URL
of the problematic tab in a new tab is usually successful."

Resizing the window 'fixes' it every time.
Might be related to 352515?
This is a much more recent regression than bug 352515 (and, FWIW, I can't remember seeing this on the branch since mento's patch in bug 370721 landed, and I used to see this several times a day).
Mass un-setting milestone per 1.6 roadmap.

Filter on RemoveRedonkulousBuglist to remove bugspam.

Developers: if you have a patch in hand for one of these bugs, you may pull the bug back to 1.6 *at that point*.
Target Milestone: Camino1.6 → ---
I just saw this tonight for the first time since I made comment 26. :(
I'm not sure what to do about this for 1.5.x (or for 1.6, frankly), but apparently I'm the only one who's seen the recurrence of this bug since bug 370721 landed.
Flags: camino1.5.2?
Flags: camino1.5.1?
Flags: camino1.5.1-
For a while today I was able to reliably reproduce this by loading a local copy of cbo/start (obtained by using a non-current UA) and twidding the link colors; reload the page, and my color changes wouldn't show (only the very first color change I made showed up).  Same with shift-reload.  Then I resized the window, and voilà, changes.

It looks like I had this lovely item in my Console during the period in which this was happening:

2007-08-17 19:25:50.614 Camino[6779] html

(but only once, and I hit this bug a dozen times in that period, so it could be spurious).  This also persisted "across tabs"; I started cmd-c the url, new tab, paste, which would pick up the last change, but if I made another change, reload/shift-reload wouldn't work, and I'd repeat the "create new tab" step to see my changes.

When I went to try in my hacked-up branch debug build, I couldn't repro, and after trying there, I could no longer trigger the bug in my daily branch nightly where I'd begun seeing it.
(In reply to comment #33)

> 
> It looks like I had this lovely item in my Console during the period in which
> this was happening:
> 
> 2007-08-17 19:25:50.614 Camino[6779] html

Was that the moment you saved an html file (from within Camino) ? I see that entry sometimes (very sometimes I should say) when saving a webpage. But no 'bad things' happen from it here.
This just happened to me again in the 10-02 branch build when trying to open the meeting agenda from the wiki's Recent Changes page :(

Nothing in the console, either :(
Not sure what to do about this; not making 1.5.2, though.
Flags: camino1.5.2? → camino1.5.2-
I'm seeing this persistently again in 1.6b3pre/2008020301 :(
Lest I come by and almost close this bug again, I've already seen this three times in a just couple of hours with 1.6.4rc :(
Has anyone seen this (that is, the summary/comment 0-4) in Camino 2.0* builds?  The chances of it getting fixed in 1.6.x are very close to 0 (I haven't seen it in 1.6.5 or 1.6.6, though!), so unless people are seeing it in 2.0b1 or nightlies, we should really just close this bug.
(In reply to comment #39)

I haven't seen this for ages.
OK, let's close this WFM-on-2.0* and hope it sticks ;)
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: