Closed Bug 157282 Opened 22 years ago Closed 20 years ago

Named anchor loads flush left only when loaded in a new background tab in Chimera

Categories

(Camino Graveyard :: Page Layout, defect, P3)

Product:
Camino Graveyard
Component:
Page Layout
Platform:
PowerPC
macOS
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME
Milestone:
Camino1.0

People

(Reporter: jcho, Assigned: mikepinkerton)

References

(
URL
)

Details

If you click a link with a unique anchor name (eg <a
href="www.foo.com/index.html#anchor">anchor name</a> and have set your prefs and
applied the appropriate modifier key (Cmd-click) to load the link to a new tab
in the background, the new page will appear with the point where the anchor tag
appears (eg <a name="anchor">anchor name</a> positioned at the top left corner
of the new tab pane, regardless of its relative position in the actual web page
layout. So if the anchor is on the extreme right hand edge of the new page,
everything on the page to its left is out of view. A simple nudge of the
scrollbar will however correct the problem.
Jeffrey, what build are you reporting this against? Can you also reproduce the
problem using Mozilla?

Adding qawanted. Needs testcase.
Keywords: qawanted
Observation based on Chimera 0.3.1 nightly build of July 10.

To observe this anomaly:

1. Go to www.macsurfer.com
2. Click on feature links from As the Apple Turns or The Mac Night Owl (these
sites use unique anchors) to load them IN BACKROUND TABS.
3. When the new page has completely loaded, switch to the new tab.
4. Page will be displaced such that anchor is at top left corner of browser window.

Just checked. Problem still present in Chimera 0.4.0 nightly build.
anchor positioning on reload/back is off
->pinkerton
Assignee: saari → pinkerton
*** Bug 157562 has been marked as a duplicate of this bug. ***
As I mentioned in bug 157562, this happens in Mozilla, too. Should we reassign
to Browser for possible duping?
if this happens in mozilla, please get it off chimera's radar.
Reassigning to Browser per comment 7.
Assignee: pinkerton → attinasi
Component: Page Layout → Layout
Product: Chimera → Browser
QA Contact: winnie → petersen
Whiteboard: DUPEME
Version: unspecified → other
Priority: -- → P3
Would this be the same case?
http://homepage.mac.com/dschrock/case.html

If so:

WORKSFORME build 20020805 MacOSX 10.1.5
Actually, Jeffrey, rereading your original description, it sounds like Mozilla
is doing exactly what it should do. What do you think Mozilla should be doing,
instead?
Perhaps it's just expected behavior, but I would think the new page shouldn't be
laterally displaced just so the anchor will appear right on the top left corner,
just at the top of page as traditionally, but respecting the lateral positioning
of the page. But if this was designed to be the Mozilla way (so user gets to
"easily" spot the anchor), so be it. 
Umm... I'd also add that the present behavior only occurs when loading the link
in a new background tab, but presents the link as one normally expects when not
using tabs, or when new tabs are set to  open in the foreground. So it probably
isn't a design decision, I think.
Jeffrey, the behavior appears to me to be the same whether or not it's loaded in
a new tab, and whether or not it's loaded in the background.
Greg,
Derek's testcase shows the positioning quirk quite clearly, except one should
see it in context: with new tabs set to open in foreground, the link target will
appear in a new tab on extreme right edge (so no matter what the page width is,
the whole target is shown); with new tabs set to open in background, the target
link is flushed to the left.

What this means is, if the target is somewhere inline in say a text passage, the
whole text passage is displaced leftwards, meaning half of it disappears out of
browser view until you "nudge" the page. This behavior is inconsistent if you
look at where the target appears in the new page when the link opens in a new
foreground/background window or in a foreground tab. Hope I'm clear enough here.
Greg, should I put up a slightly revised test case to (hopefully) show what I mean? 
I think this is the effect you're looking for?
Think of "testing" as being the anchor in both cases (even though that's not the
case if you look at the HTML)
http://homepage.mac.com/dschrock/case/

Seems like you want to change Mozilla because a page isn't large enough for your
browser window?
Not really. See my test-case to understand what I'm getting at:

http://homepage.mac.com/choj/anchortest1.html

Compare with new window fore/bkgd and new tab foreground.
Well, I'll be damned. Jeffrey, you're right after all. Using your testcase, the
link text is absolutely flush left, only in Chimera, and only when loaded in a
new background tab. My apologies for doubting you.

Reassigning back to Chimera/Page Layout.
Assignee: attinasi → saari
URL: http://homepage.mac.com/choj/anchorte...
Component: Layout → Page Layout
Keywords: qawanted
Product: Browser → Chimera
QA Contact: petersen → winnie
Summary: Layout problems when loading target links with with unique anchor names in background → Named anchor loads flush left only when loaded in a new background tab in Chimera
Whiteboard: DUPEME
Version: other → unspecified
Phew! Next time I report a bug, I'll be sure to start off by presenting a
test-case. :-)
Greg, there's something else I discovered while preparing the test-case:

The table I used for the test-case was set to a specific pixel width (770px).
However, if the table width is set to a percentage, or no width is specified, it
gets even odder.

The new background tab presents a blank page, and the scrollbar indicates you
are at the bottom of the page. You click to scroll up the scrollbar, and the
page comes into view, but then the scrollbar is unresponsive for at least two
mouseclicks. And it's after a couple more clicks that the scrollbar finally
responds, and you finally see the link target.

Pse see http://homepage.mac.com/choj/anchortest1.html again if you'd like to see
this other quirk.

Fixing the other problem will probably solve this one.
I was going to enter this as a new bug but I searched and found it.

I get this behavior in Chimera, and only Chimera. Here's another test-case, from
the environment that consistently makes it happen:

1. go to http://www.livejournal.com/users/peganthyrus/2003/04/05/
2. right-click on the 'Vanishing, disconnected pieces.' link and open in new tab.
3. Go to the opened tab and observe how everything is offset bizarrely, possibly
with a grey border around the edge of the actual content - and yet the scroll
bar is at the top. When you play with the scroll bar, or hit the home key, or
otherwise move the position about, it will display properly.
In context to comment #21 it's WFM... the scrollbar appears to be in the correct
postion also it's offset to the begining of the "read more" section.

Note the paragraph before "I was an observer, ..." is the text that's on the
main page.
Ah! I'm horribly confused.

Forget comment #22

Able to reproduce with Camino 2003043015

here's another URL:
http://www.freebsd.org/news/press.html#2003March:0
*** Bug 204221 has been marked as a duplicate of this bug. ***
i have no idea what's going on here. does this still happen on nightly builds?
Assignee: saari → pinkerton
wow, we've had this bug for a looooong time and we still do. sigh.
Target Milestone: --- → Camino1.0
Tested on 2004011403 (v0.7+), still there :( This one seems like a PITA bug.
with 2004090408 (v0.8+) this WORKSFORME anyone care to confirm ?
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
WORKSFORME as well in 2004090608 (v0.8+). Used slashdot as my test case as this
is where I first noticed the problem. Open a story in some mode where you will
see the "1 reply below your threshhold" link, and cmd+click that reply into a
new tab.

The page loads fine now. 
Verified WFM using 0.8.1.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.