Closed Bug 602539 Opened 15 years ago Closed 15 years ago

Mac OS X Fennec does not show remote pages.

Categories

(Firefox for Android Graveyard :: General, defect, P2)

Product:
Firefox for Android Graveyard
Component:
General
Platform:
x86
macOS
Type:
defect

Tracking

(fennec2.0+)

Status:
RESOLVED DUPLICATE of bug 625060
Tracking Flags:
Tracking Status
fennec 2.0+ ---

People

(Reporter: nhirata, Assigned: jaas)

References

Details

1. download the nightly build 2. run it and go to url http://www.google.com Expected google loads Actual grey screen Note: 1. Beta 1 rc 3 build works fine; bug 599198 2. just the nightly seems not working.
Assigned to dougt by his request.
Assignee: nobody → doug.turner
Forgot to place in build : Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b7pre) Gecko/20101007 Firefox/4.0b7pre Fennec/4.0b2pre
On m-c and mobile-browser respective tips, I've got a completely responsive content process. How mysterious.
Windows Fennec does not show remote pages. Linux Fennec does show remote pages.
i only see content when i click on the content area.
Summary: Nightly build of Mac OS X Fennec does not show remote pages. → Nightly build of Mac OS X and Windows Fennec does not show remote pages.
This should block b2...nominating.
tracking-fennec: --- → ?
yup, it should.
tracking-fennec: ? → 2.0b2+
nhirata, can you find the last know good build? I think it was: 27-Sep-2010 03:16 Build 28-Sep-2010 03:37 was busted with a different problem.
I think the builds before the 27th didn't have --enable-ipc turned on, so they're useless. I don't believe we've had a working IPC nightly, but somehow the beta and my personal builds work fine.
jdm - not very reassuring. No real regression range. Does the nightly work for you? http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/latest-mozilla-central-macosx/fennec-4.0b2pre.en-US.mac.dmg nhirata - ignore the request to find anything.
Nope, the nightlies are busted for me - gdb shows that the content process segfaults as soon as you try to load anything. I was hoping to use the symbol server to get a more informative backtrace than ???, but the fennec symbols aren't set up correctly and there's no movement in the bug I filed (bug 602859).
Morphing a bit: filed bug 603547 for the crashreporter (on the stack) crash. This crash is on both the Mac and windows. Leaving this bug open for the Mac-only no-page-content until you zoom/double-tap issue
Summary: Nightly build of Mac OS X and Windows Fennec does not show remote pages. → Mac OS X Fennec does not show remote pages.
Both child and parent are deadlocked. The child looks like: #0 0x00007fff887412fa in mach_msg_trap () #1 0x00007fff8874196d in mach_msg () #2 0x00007fff85b0d3c2 in __CFRunLoopRun () #3 0x00007fff85b0c84f in CFRunLoopRunSpecific () #4 0x00007fff842fc91a in RunCurrentEventLoopInMode () #5 0x00007fff842fc71f in ReceiveNextEventCommon () #6 0x00007fff842fc5d8 in BlockUntilNextEventMatchingListInMode () #7 0x00007fff8742c29e in _DPSNextEvent () #8 0x00007fff8742bbed in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] () #9 0x00007fff873f18d3 in -[NSApplication run] () #10 0x00000001012cd328 in nsAppShell::Run (this=0x1060924f0) at /builds/mozilla/mozilla-central/widget/src/cocoa/nsAppShell.mm:747 #11 0x0000000100045fe6 in XRE_RunAppShell () at /builds/mozilla/mozilla-central/toolkit/xre/nsEmbedFunctions.cpp:631 #12 0x00000001013cd054 in mozilla::ipc::MessagePumpForChildProcess::Run (this=0x105614bd0, aDelegate=0x7fff5fbff0c0) at /builds/mozilla/mozilla-central/ipc/glue/MessagePump.cpp:220 #13 0x000000010162b35d in MessageLoop::RunInternal (this=0x7fff5fbff0c0) at /builds/mozilla/mozilla-central/ipc/chromium/src/base/message_loop.cc:219 #14 0x000000010162b375 in MessageLoop::RunHandler (this=0x7fff5fbff0c0) at /builds/mozilla/mozilla-central/ipc/chromium/src/base/message_loop.cc:202 #15 0x000000010162b3d6 in MessageLoop::Run (this=0x7fff5fbff0c0) at /builds/mozilla/mozilla-central/ipc/chromium/src/base/message_loop.cc:176 #16 0x0000000100046f98 in XRE_InitChildProcess (aArgc=1, aArgv=0x7fff5fbff390, aProcess=GeckoProcessType_Content) at /builds/mozilla/mozilla-central/toolkit/xre/nsEmbedFunctions.cpp:506 #17 0x0000000100000def in main (argc=3, argv=0x7fff5fbff390) at /builds/mozilla/mozilla-central/ipc/app/MozillaRuntimeMain.cpp:78 It has an IPC event that is queue but isn't sending to the parent. None of the MessagePumpCFRunLoopBase methods in the child are ever called. I thought that is how IPC was hooked up to the native event look. It also looks like this is the reason for a page load rarely completing if you do not click in the content area on the Mac, as well. Ben, Josh - Any ideas?
I have strong suspicions that this is resolved by the patch in bug 606052. I haven't hit this since I applied it.
not blocking 2.0b2. The behavior is wrong, but you can load pages (you just have to tab the browser when the page load get stuck). This is a mac platform bug. Josh Aas, can you look into it?
Assignee: doug.turner → joshmoz
tracking-fennec: 2.0b2+ → 2.0+
Priority: -- → P2
What is the status here?
same thing in last nights nightly.
Well, I'm somewhat perplexed here, because I'm 99.9999% sure this is a dup of bug 625060 but that was blocking-'d. If I were to dup it then we that would send this bug to the don't-care bin. Can we please get consistent guidelines for blocking status of bugs affecting fennec-on-mac/windows-desktop?
Hmm, I think bug 625060 read like "get testing framework setup" and this reads more like "stuff is broken"
Quoting bug 625060 comment 3: "If we're serious about fennec extension developers using mac nightlies, then this ought to block for similar reasons as bug 617860 did. The bug I'm about to post a patch for is quite bad." Then later comments explained what the underlying bug was and how it affected fennec.
And if we were to turn on the existing code to allow the testing framework, this would all be a moot point. Yes, I'm very frustrated about this.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.