Bug #66958

[Germain Garand]

> > But then is there a real need for a separate key combination/hardReload
> > argument?
>
> Action and key combination isn't necessary of course. As I said in my
> previous mail, it was my initial hack to test whether my idea works at
> all.
>

> But there has to be the way to make sure it's user initiated reload, not
> usual "open url" to make 'open already opened url' case to work. How else
> we can know whether user hit the reload button (going to reload
> individual frames) or moved cursor into url bar and just hit enter (going
> to reload whole frameset)?

currently, args.reload is what is used for that purpose. 
see e.g. the jumping to #anchor behaviour differences.

The 'open already opened url' case (hitting enter in URL bar) is just a normal 
openURL, with false args.reload, where the new url just happen to be == to 
the old url so there is no distinction problem.

Of course if someone does step up to implement other behavioural differences 
between a "hard" and "soft" reload then there is indeed a need for it (but 
then please make sure, when you forwardport your patch to trunk, that those 
reload/softReload conflicting booleans are merged into a single enum!).

>
> Briefly tested patch is attached.
>
>
> PS. Btw, I found it quite confusing having "reload" member in URLArgs
> structure, but finding that it's about cache policy. Maybe it's good idea
> to rename it?

I'm not sure what gave you this idea? it's not about cache policy. It does, 
among other things, happen to set a Reload cache policy for obvious reasons, 
but it isn't reducible to that.

Greetings,
Germain