can you check it works from a 'known good' browser/OS combo? I'll see if I can reproduce the problem...did you install from live, netinst or DVD? thanks!

triaging to kde-baseapps component (where konqueror lives).

Fwiw, I can't reproduce the problem on my f18 box with same kde/konqueror version, so *may* be f19 specific somehow.  Been meaning to get a fresh f19 install going, may as well be now.

I performed this test on 8 arch-DE combinations and it worked 50% of the time as follows:
F19-Alpha-TC3-i386 Gnome-Firefox -- Worked
F19-Alpha-TC3-x86_64 Gnome-Firefox -- Worked
F19-Alpha-TC4-i386 Gnome-Firefox -- Worked
F19-Alpha-TC4-x86_64 Gnome-Firefox -- Worked
F19-Alpha-TC3-i386 KDE-Konqueror -- Failed
F19-Alpha-TC3-x86_64 KDE-Konqueror -- Failed
F19-Alpha-TC4-i386 KDE-Konqueror -- Failed
F19-Alpha-TC4-x86_64 KDE-Konqueror -- Failed

Confirming the issue. I can reproduce it on F19 Alpha TC4. However, as Rex mentions, it works on F18 with same version of kde-baseapps - kde-baseapps-4.10.1-1.

For completeness, this violates the following criterion:

"It must be possible to run the default web browser and a terminal application from all release-blocking desktop environments.

The web browser must be able to download files, load extensions (if applicable), and log into FAS."

Interesting note: I can't reproduce the issue in live environment. Seems it affects only installed system. Tested on both TC4 and T5.

Also worth noting, Firefox when installed on KDE will reach FAS2 site ok.  Konqueror still does not.

Those of you testing installed F19, is this with any updates installed or not?

(if updates installed, I'd argue the cause could be something currently in -testing possibly causing this, then it's not a blocker)

Another possibility how to avoid blocking on this issue is KHTML engine - could you please try to switch to KHML? View -> View Mode -> KHTML and retry? At least we could say it's Konqueror bug or QtWebKit one.

Problem with kded4 appears on installed systems but not on live image.

kded4: symbol lookup error: /usr/lib/kde4/kded_kscreen.so: undefined symbol: _ZN7KScreen6Output14setCurrentModeEi
kio_http(1138)/kio_http_debug HTTPProtocol::findCookies: Can't communicate with kded_kcookiejar!

Looks like mismatched kscreen and libkscreen, resulting in kded4 not loading, and thus NO kded4 service loading, including kcookiejar.

kscreen-0.0.81-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/kscreen-0.0.81-1.fc19

Whaddayaknow, that ridiculous test case caught a legitimate bug? Amazing.

Rex can't speak for others but my testing is done on fresh from DVD installs.

+1 blocker based on criterion cited in comment #5. Can others please give blocker votes on this so we can pull it into TC6/RC1? Thanks!

+1 blocker here.

+1 blocker based on the criterion cited in comment #5. That makes for +3 blocker, moving it to accepted

Package kscreen-0.0.81-1.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kscreen-0.0.81-1.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-5007/kscreen-0.0.81-1.fc19
then log in and leave karma (feedback).

*** Bug 949129 has been marked as a duplicate of this bug. ***

kscreen-0.0.81-1.fc19 and a reboot resolved the issue for me.

I have tested with F19-Alpha-TC5 both i386 and x86_64 installs.  Test Procedure as follows:
1.  Wait for GUI Install to reach <REBOOT> point.
2.  Switch to text tty with <CTRL><ALT><F2>
3.  chroot /mnt/sysimage
4.  yum update kscreen --enablerepo=updates-testing
5.  Respond as needed to yum and let it complete
6.  Reboot the System.

Saw the following results:
In both arch it works

kscreen-0.0.81-1.fc19 fixes the issue for me as well.

kscreen-0.0.81-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.